ilert seamlessly connects with your tools using our pre-built integrations or via email. ilert integrates with monitoring, ticketing, chat, and collaboration tools.
See how industry leaders achieve 99.9% uptime with ilert
Organizations worldwide trust ilert to streamline incident management, enhance reliability, and minimize downtime. Read what our customers have to say about their experience with our platform.
Not all alerts are created equal. Some are resolved quickly by the on-call engineer. Others signal something serious enough to affect your business and require your whole team to coordinate. That is why we redesigned incidents as a dedicated coordination workspace for the alerts that have the most business impact.
Until now, incidents in ilert were used to communicate status updates to customers and stakeholders. Creating one meant publishing to your status page. We have separated the two. Incidents are now internal. Status updates remain the way you communicate externally, and they go out only when you choose to post one.
Inside an incident, your team can create an incident channel, run parallel escalations, track the timeline, manage status, and create post-mortems. Nothing reaches your customers until a status update is published.
Here is what changed and what is new.
Incidents are now your internal coordination workspace
Previously, creating an incident in ilert meant publishing an update to your status page directly. Incident coordination lived inside alerts, and information went public the moment an incident was created.
That's no longer the case, incidents are internal; nothing is public until you post a status update. Creating an incident opens an internal workspace for your response team, and nothing reaches your status page until you choose to publish a status update. The two are fully decoupled.
Alerts, incidents, and status updates
With this change, ilert now has three clearly separated objects, each with a different purpose:
Alerts have not changed. They signal issues and page your team.
Incidents are now a dedicated internal workspace for coordinating your response. They are no longer tied to your status page.
Status updates are now separate from incidents. They are how you communicate with customers and stakeholders when you are ready.
Your existing incidents will be migrated automatically to status updates. Nothing has been deleted.
Declare incidents with severity and a dedicated channel
Two new fields appear when you declare an incident: severity and incident channel.
Severity
Severity lets you classify the business impact from the moment of declaration, which is useful for routing, reporting, and setting expectations with your team. When declaring an incident, severity is set to SEV3 by default and can be changed depending on your context.
Incident channel
A dedicated channel can be created when you declare an incident. Previously this was done from alerts. It now lives in the incident, where all the context for that response is kept in one place.
A full response workspace: parallel escalation, incident commander, status, timeline, and post mortems
Once declared, the incident becomes the single place your team coordinates the response.
Parallel escalation
Page multiple teams and individuals at the same time when you declare an incident. You do not have to wait for one escalation chain to step through before paging the next.
You can trigger all of these simultaneously:
An escalation policy
An on-call schedule
A full team, which pages every member at once
A specific user, directly
When paging a team directly, the first member to join the incident stops the page for others, who receive a "page resolved" notification.
Incident commander
Assign a named person to own the response, giving the team a single point of accountability from declaration through to resolution.
Incident status
Status can be tracked and updated as the team works on the situation, keeping everyone internally informed on where the response stands.
Incident timeline
The incident timeline records every action, page, and change automatically in real time. Useful while the incident is running, and essential when writing the post mortem.
Post mortems
Post mortemshave moved from status updates to incidents, where the full record of what happened actually lives. When you resolve an incident, a post mortem can be created and populated from the timeline, incident channel messages, and linked alerts.
Status updates: communicating with stakeholders
What was previously called an incident on your status page is now called a status update. The functionality is unchanged. Status updates now have their own dedicated page in ilert.
There are two ways to create a status update.
Post status update from status updates page
The status updates page gives you a dedicated view of all your published updates. Filter by service, status page, and creation date, and post new updates directly from there.
Post status update from incident (recommended)
Work the incident internally, then publish a status update when you are ready to communicate externally. The status update is linked to the incident, keeping your internal coordination and external communication connected.
In short, incidents now serve as an internal coordination layer with a dedicated set of tools to support your team during response. Status updates remain unchanged and are the communication layer used to inform your customers and stakeholders.
If you have any questions or need support navigating the new setup, reach out to your Customer Success Manager or contact our support team.
Changes will start rolling starting Monday, July 20th. If you want to expedite the switch, reach out to us at support@ilert.com.
New to ilert? Incident management is available on all plans. Try it for free and see how your team can coordinate faster when it matters most.
From a redesigned navigation and the new ilert Marketplace to dynamic service mapping and on-prem alert delivery, here's everything that's shipped across this quarter.
Navigation
A new way to navigate ilert
We've redesigned ilert's navigation to keep your operational work front and center while giving the rest of the platform room to breathe. Your day-to-day views: Dashboard, Alerts, Incidents, and My on-call, now live in a persistent top bar, and everything else moves into a new vertical sidebar with three ways to work:
Keep the full menu open, with labels and section headings.
Collapse it out of the way to reclaim screen space.
Toggle between the two with the hamburger button.
Open your profile menu and switch on "New navigation" to try it.
Every page in ilert is now searchable
Every page in ilert is now reachable from the global search bar. Click the search icon and start typing: Alert sources, Escalation policies, Heartbeat monitors, Audit logs, and you'll land there in seconds.
Click the search icon to try it. A new ⌘K / ctrl+K command palette lets you jump to any page or entity in a single keystroke.
Alerting & Incident Management
Dynamic service mapping
Dynamic service mapping is here. Define which alert fields carry your service information such as labels.service from Grafana, tags.service from Datadog and ilert automatically extracts those values and links the relevant services to every incoming alert. No more manual tagging. And when a service doesn't exist yet, enable auto-create and ilert provisions one for you, ready for review.
A head start on alert templates
Building an alert template from a blank page meant knowing every variable and field, and how you wanted them laid out, before you could see anything useful. Now, when you set up a template for one of our most popular integrations, you'll find a default already filled in, modeled closely on how ilert formats those alerts out of the box, so you start from a working template instead of zero. Edit any part of it, leave the rest, and ship. Try it next time you create or edit an alert source template.
Find the maintenance window you need, faster
The maintenance windows list now supports the same filters as our API: narrow results by service, by alert source, and by date range with from/until pickers. Whether you're auditing past windows for a specific service, checking what's scheduled on a given alert source, or pulling up everything happening next week, you can get there in a couple of clicks instead of scrolling. Filters combine, and the URL updates as you go, so you can bookmark or share a filtered view with your team. Head to Alerting → Maintenance windows to try it.
Filter alert reports by severity
Alert reports now support filtering by severity, so you can analyze your data the way your team triages it. Filter by any combination of levels 1–5 (or "None"), and stack it with existing filters for teams, sources, escalation policies, responders, priority, and labels. Open any alert report parameters and look for the Severity selector under Filters.
Connectivity
Reach tools behind your firewall with the Edge Connector
ilert alerts can now reach tools behind your firewall. The new Edge Connector runs inside your network, pulls events from ilert, and delivers them locally to your on-premise systems, no inbound ports, no firewall changes. Read the Edge Connector docs to get started.
Billing
Self-serve quotes, no email exchange required
Needing a formal quote for procurement used to mean emailing us and waiting for someone to put one together. Now you can do it yourself. Head to quotes.ilert.com, pick your plan, set your user count and add-ons, choose monthly or yearly, fill in your company details, and you'll get a professionally branded PDF quote in your inbox in seconds, no ilert account required, so you can share the link with whoever owns the buying decision.
When it's time to subscribe, paste the quote ID into the "Have a quote?" field at checkout and your plan, seats, and add-ons are pre-filled exactly as quoted. Enterprise quotes (50+ users) still run through sales@ilert.com so we can tailor terms to your organization.
Marketplace
Introducing the ilert Marketplace
The ilert Marketplace is a new home for apps that extend what ilert can do. It launches with two apps built to keep your team covered and healthy.
Notification Preference Policy
Notification Preference Policy lets you audit notification compliance across your team. Define the policies that matter: required channels, escalation delays, then instantly highlight any users whose preferences don't meet your coverage requirements. When gaps appear, auto-fix brings them into line in a click, so no critical alert slips through because someone wasn't set up correctly.
On-call Health
On-call Health turns your scheduling data into insight. Analyze on-call schedules to surface health metrics, risk factors, and trends across your teams, spot burnout before it takes hold, and make data-driven decisions that improve on-call quality. It also factors in legal limits by country, so your rotations stay compliant with regional working-time regulations wherever your team is based.
Both apps are available now. Find the Marketplace under your profile menu.
New Integrations
Uptime: Uptime is a cloud-based website monitoring platform that checks the availability, performance, and functionality of websites, APIs, and services from 80+ global monitoring locations, with checks running as frequently as every 30 seconds.
Wazuh: Wazuh is an open-source security platform from the US, it unifies XDR and SIEM capabilities to protect workloads across on-premises, virtualized, containerized, and cloud environments.
Sekoia: Sekoia is the European cybersecurity company building the Cyber Operations Platform for the AI era. Unifying threat detection and response, cyber threat intelligence, exposure management, and agentic AI, Sekoia is rebuilding cybersecurity from the ground up.
It’s 2:47 a.m. A P1 alert fires. The on-call engineer opens ilert, sees the AI has already investigated, and is presented with three remediation options. What happens next is the moment we obsessed over.
Most AI tooling at that moment hands the engineer a numbered list in a chat window and waits. The engineer reads, selects mentally, types a reply, and the agent resumes. That sequence takes seconds under pressure, but it also introduces ambiguity, re-reading, and cognitive overhead at exactly the wrong moment.
We’re building an SRE Agent, an AI agent embedded directly inside ilert’s incident response platform to handle everything from RCA and triage to on-call queries and object creation. As we made agents a first-class part of the product, one question kept coming up: what’s the right interface for a human approving an AI decision during an active incident?
Chat is the obvious default. But it’s not always the right one.
Does the agent run as a sidecar? An overlay? Is there a dedicated place to talk to it? Is chat the only interface?
Chat has one strong argument going for it: the agent can be wherever the user is: Slack, WhatsApp, Teams. Whenever it needs input, it reaches you on your preferred channel.
But chat also has real drawbacks. In many cases, it’s still too much input. Users don’t always know what to type or where to start. And when you push the interaction into a chat channel, you’re limited to what that channel supports, which usually means text.
Here’s how we’re approaching it at ilert:
The bet is that the best agent UX won’t feel like a chatbot. It’ll feel like the product got smarter. ActionOption Cards are where that thinking gets concrete, and they start by solving one very specific piece of friction.
The problem with plain-text option lists
Back to 2:47 a.m. The AI has already done the hard part: correlated signals across Datadog and GitHub, identified a bad deploy, and narrowed the options to three. That work matters. What happens next can undo it.
Most AI tooling hands the engineer a numbered list in a chat box and waits. That forces them to read, mentally select, and type a confirmation back, friction at exactly the wrong moment, and ambiguity that the agent then has to resolve. The pattern looks like this:
1. Scale up the payment-gateway deployment
2. Restart the affected pods
3. Roll back to the previous version
This forces the user to read the option, mentally select it, and type a follow-up message to confirm their intent. That is friction at exactly the wrong moment. It also introduces ambiguity, did the user mean option 1 exactly, or a variation of it?
The interface should be decisional, not just conversational. During an active incident, engineers operate under cognitive load. Every second spent re-reading, re-parsing, or re-typing is a second the incident continues.
What are A2UI (agent-to-user interface) ActionOption cards?
We are using the A2UI framework for dynamically rendering interactive UI elements inside the agent conversation thread, components that the agent generates on the fly, not static screens. An ActionOption Card is the primary way it is expressed: it’s what the agent renders instead of a numbered text list whenever a user action is required.
Each card represents a single, discrete course of action and is composed of:
Title: A short, unambiguous label for the action, e.g. “Option 1: Scale up payment-gateway”.
Description: An explanation of what the action does and the trade-offs it involves, so engineers can make an informed decision at a glance.
Tag badge (optional): A colour-coded label: Recommended (green), Immediate (amber), Quick (blue), or Best (green). Only rendered when it meaningfully differentiates an option.
Action button: A clickable button with a short action verb and an optional icon. One click is all that’s required to proceed.
A simple example: the agent proposes three options. Instead of typing “1”, “2”, or “3”, you click a button. This pattern scales into more complex scenarios: selections, sliders, rich tables.
Technical architecture: How cards are generated and rendered
Three things make it work: the LLM, a thin tool layer, and the frontend.
Step 1: Tool call
We built a dedicated tool that the agent can call whenever it decides structured options make more sense than a plain text reply. The LLM passes a list of option objects, one per card:
{
"options": [
{
"title": "Scale up payment-gateway",
"description": "Increase replica count from 3 to 6 to absorb current traffic spike. No downtime expected.",
"tag": "Recommended",
"risk": "low",
"effort": "~2 min",
"actionLabel": "Scale up"
},
{
"title": "Option 2: Roll back to v2.4.1",
"description": "Revert the deployment to the last stable version. Resolves regression but requires redeployment.",
"tag": "Immediate",
"risk": "medium",
"effort": "~10 min",
"actionLabel": "Roll back"
}
]
}
Step 2: Rendering
For each option, a unique identifier is generated. An A2UI surface update command is then published to the backend message bus. The frontend subscribes to these events and renders the cards in real time within the conversation thread as they arrive, no page reload, no manual polling.
Step 3: User interaction and intent injection
When the engineer clicks an action button, an event carrying the option's unique identifier is sent back to the agent. The agent maps this to a pre-configured confirmation sentence, for example, "Yes, scale up the payment-gateway replicas", and injects it into the chat thread as if the user had typed it themselves. This seamlessly resumes the LLM loop with the user's confirmed, unambiguous intent.
Step 4: Post-selection state
Once the engineer clicks, the card updates its own state: the action button is replaced with a green checkmark labelled "Selected". This visual confirmation makes it clear the action has been acknowledged and prevents accidental double submissions.
Why this pattern matters
This is ilert’s answer to a question every AI SRE vendor is navigating: how much should the agent do autonomously, and when does it hand back to a human? Our answer is that the handoff moment needs to be as frictionless as the investigation that precedes it. ActionOption Cards are built for that moment. Here’s what that means in practice:
Visual scannability. Cards are spatially separated, visually distinct, and carry structured metadata. An engineer can evaluate three options at a glance rather than reading a paragraph of text.
Explicit risk and effort signalling. Rather than leaving the risk assessment to intuition, the agent surfaces risk and effort data directly alongside each option, information drawn from runbooks, historical incident data, or its own analysis.
Unambiguous intent. A clicked button maps to an exact, machine-readable action. There is no natural language ambiguity between “scale it up” and “increase the replicas”. The identifier-to-sentence mapping ensures the LLM receives exactly the intent the engineer confirmed.
Resumable agent loop. Because the injected confirmation sentence re-enters the chat thread like any other user message, the LLM loop resumes without special-case handling. The agent continues its workflow as if the engineer had typed the response naturally.
The click is the governance
A lot of AI SRE products talk about human-in-the-loop as a safety concept. ActionOption Cards make it a UX reality. The engineer doesn’t approve an action by typing “yes” into a chat box, they click a button that surfaces the risk, the effort, and the trade-off at a glance. The approval is informed and it’s fast.
That’s the difference between an AI agent bolted on top of a product and one that’s built into it. The agent earns autonomy gradually, and at every step, the human approval moment is designed to be as clear and fast as the AI investigation that preceded it.
Back to 2:47 a.m. The AI investigated. Three options are on screen. One click.
.png)
.png)
.png)
.png)
.png)
.png)
