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.
ilert AI SRE is now generally available. Alongside it, this quarter brings Compass, a lifecycle assistant that surfaces the next move during an incident, a dedicated space for postmortems, rich incident cards in Microsoft Teams and Google Chat, on-call schedules that follow support hours and holidays, a new CLI, and dark mode. Here's everything that shipped.
ilert AI SRE
ilert AI SRE is now generally available
ilert AI SRE is now generally available on every paid plan and during trials. Start an investigation from an alert, from an incident, or by describing what you're seeing in the agent's chat. The agent searches logs, metrics, traces and recent changes, including deployments, config changes and merged pull requests. When an alert storm hits, it first triages the alerts into clusters and then investigates each one.
Every investigation returns a root cause hypothesis with a high, medium or low confidence label, key findings linked to their evidence, what it ruled out, and, where it makes sense, a proposed action such as a rollback. Nothing changes on your systems until an engineer approves it. In our chaos tests across a dozen fault scenarios, the median time from alert to first finding was 194 seconds. AI runs the investigation. You make the call.
All AI workloads run on dedicated infrastructure in our EU regions, Frankfurt and Stockholm. We don't train on your data and have opted out of training with every model provider we use. AI SRE runs on the AI credits included in your plan: 250 per month on Pro, 1,000 on Scale and 5,000 on Enterprise. Read the GA announcement for how it works and how we test it, or see the ilert AI SRE page. To set up your first agent, see the AI SRE docs.
Incident Management
Compass: your incident lifecycle assistant
Compass is the newest addition to incident management in ilert. During an incident, it follows along with you and surfaces the next move: start an AI SRE investigation, post a status update when your status page is out of date, or resolve the incident once things have stabilized. When nothing needs doing, Compass tells you that too, so it keeps noise to a minimum. More in the incident docs.
Postmortems get their own space in ilert
Postmortems now have a dedicated space in ilert. When an incident is resolved, use ilert AI to draft a postmortem from the full incident context, including the timeline and chat conversations. Edit or add sections until the draft is right, then publish it internally or to your status page. More in the postmortem docs.
Service topology and the Service Health map
Service topology gives you a live map of your services and how they depend on each other, built automatically from your OpenTelemetry traces instead of a static architecture diagram. Connect a telemetry source and point your OpenTelemetry Collector or SDK at ilert’s OTLP endpoint. ilert derives the service-to-service dependencies, adds new services to your catalog, and keeps the graph current as traces arrive. It’s push-based, so you never share credentials with ilert.
During an incident, select a service on the Service Health map to see its blast radius upstream and its root-cause candidates downstream, next to its open alerts and recent incidents. AI SRE also uses the graph during alert triage to work out where a problem starts.
We shipped an updated ilert CLI: one binary for you, your pipeline and your AI agent. It builds its command tree from ilert's OpenAPI spec at runtime, so every API endpoint is reachable and the CLI can't fall behind the API. Sign in with ilert auth login, or set ILERT_API_KEY in CI.
Point Claude Code, Codex, Cursor or any other agent at it, and anything you can do in ilert, your agent can do too, described in plain language instead of clicked through a UI. Ask it who is on call for payments-platform right now and what happens if they miss the page, or have it create an alert source for checkout-api, route it to the right schedule and hand you the integration key.
It's built to be safe to hand over. Destructive commands don't run unattended, --dry-run shows the whole plan before anything is sent, output is machine-readable, and credentials stay out of the conversation.
The CLI also takes the manual rebuild out of switching providers. Your agent reads your current Opsgenie, PagerDuty or other setup with a read-only token, then stages the rebuild in ilert with --dry-run in dependency order: users and teams, then schedules, escalation policies, alert sources and status pages. Nothing changes until you approve the plan.
Run incidents from Slack, Microsoft Teams or Google Chat
Rich incident cards now render in Microsoft Teams and Google Chat, not just Slack. Your team can acknowledge, escalate and resolve incidents from the chat tool they already live in.
Slack cards also gained a fully rendered resolved state, and chat surfaces now follow the detected language automatically instead of defaulting to English. More on ChatOps in ilert, or set it up with the ChatOps docs.
On-call Management
On-call schedules can now follow support hours, holidays included
Recurring schedules can now follow a support hour directly. Set a layer's coverage to "Follow support hours (respects holidays)" and it inherits that support hour's weekly windows and holiday exceptions. The rotation then skips coverage on a holiday automatically, or adds it back if the support hour says otherwise, without you editing the rotation itself.
Edit the support hour later, add a holiday or change the weekly window, and every schedule following it updates automatically from then on. Past coverage stays as it was.
You can also see the connection from the other side. A support hour's "Used in" panel now lists every schedule that follows it, alongside the alert sources using it, so you know what depends on a support hour before you change it. More on on-call management in ilert, or see the docs on recurring schedules and support hours.
A multi-language responder experience
The ilert mobile app and the notifications ilert sends to responders now follow each responder's language setting, with Spanish, French and Italian joining English and German. Pick French, and the voice call that wakes you at 3 a.m. briefs you in French. Translations are generated automatically with every release, so new features reach every language at the same time. The web app stays in English.
User Experience
Dark mode in ilert
You can now choose how ilert looks. Open your profile menu, go to Appearance, and pick light, dark or follow system. Dark mode is available to everyone today.
New Integrations
Bleemeo: Bleemeo is a cloud monitoring platform for servers, containers, Kubernetes and cloud infrastructure. Its alerting rules watch your metrics and raise an alert when a threshold is breached. Set it up with the Bleemeo integration docs.
DBmarlin: DBmarlin is a database observability and performance monitoring tool that tracks database instances, hosts and the changes that affect them. Its alert rules fire when statistics such as query time, executions or host CPU cross a threshold. Set it up with the DBmarlin integration docs.
OpenNMS: OpenNMS is an open-source network monitoring and management platform that discovers your infrastructure, collects performance data and turns events into alarms. Set it up with the OpenNMS integration docs.
Sneak peek: Actions (closed beta)
Actions run work in your other tools whenever an alert or incident changes: open a Jira issue when an alert is created, call a webhook when an incident is resolved, or send an email. Each action lives in its own Actions area instead of on an alert source. You decide what it covers: every alert source, your teams, specific alert sources or, for incidents, specific services.
They run automatically on the trigger events you choose, from acceptance and escalation to comments and linked postmortems. A user can also start one manually on a single alert or incident. The first run links the alert or incident to what it created, so later runs update the same Jira issue instead of opening a new one. Turn on bidirectional sync and changes flow back too: move the issue to Done and the alert resolves.
Database alerts from DBmarlin can now go straight to ilert. When an alert rule fires on slow queries or an overloaded database host, ilert pages whoever is on call, escalates if they don't respond, and hands them a link back into DBmarlin, where the diagnosis lives.
What is DBmarlin?
DBmarlin is a database observability and performance monitoring tool built by Application Performance Ltd (AP), a UK company based in Fleet, Hampshire. It monitors twelve database engines from one console across self-hosted databases and managed services such as Amazon RDS, Azure, and Google Cloud SQL. It runs self-hosted or as SaaS, with a free tier for one database instance.
Where general observability platforms show that a database call is slow, DBmarlin shows what is happening inside the database. It captures SQL statement text and wait states, and auto-detects changes to schema objects, database parameters, and explain plans, so teams can tie a slowdown to the change that caused it. The team has deep roots in the space: its founders met at Precise Software, and AP's earlier database monitoring product, DBTuna, was acquired by AppDynamics.
Alerting runs through alert rules, which watch statistics such as query time, executions, or host CPU on database instances and hosts, and fire when a threshold is breached.
Why route DBmarlin alerts through ilert?
DBmarlin shows you where the time went inside the database and what changed before it slowed down. It doesn't decide who needs to hear about it at 3 a.m., or what happens when that person sleeps through the first notification. That part is ilert's job.
When the problem outgrows one responder, the alert can grow with it: promote it to an incident with a dedicated channel and incident commander, keep customers informed through a status page, and write up what happened in a postmortem afterwards.
A few details make these alerts easier to act on:
Responders see the numbers. Each alert carries the rule name, the statistic, its previous and current value, the threshold and units, the time window, and the affected host or database instance, so whoever reads it on a phone can tell how far past the threshold things are. Fields you add to the template appear as custom details on the ilert alert.
The diagnosis is one click away. Every alert includes a deep link into DBmarlin. Point the DBmarlin URL at an address your responders can reach from their own machines; localhost only resolves on the DBmarlin host itself.
Alerts close when the condition ends. Host alert rules send an ended event, and ilert resolves the matching alert when it arrives, so nobody starts the morning clearing stale alerts. For database instance alert rules, add one eventType line to their template to get the same behavior.
Your database telemetry stays where you run it
DBmarlin can run self-hosted, which keeps SQL text, wait states, and performance history inside your own environment. The integration doesn't change that. What reaches ilert is exactly what the webhook template defines: rule name, statistic, values, host or instance name, and the deep link. Edit the template and you send less.
The alert itself lands with ilert, which is made and hosted in Germany, ISO 27001 certified, and GDPR compliant. When a security review under GDPR, NIS2, or DORA asks what database data leaves your environment for paging, the answer is a short payload you define, sent to an EU-hosted provider.
Connect DBmarlin to ilert in three steps
1. Create the alert source in ilert
Under Alerting → Alert sources, click Create new alert source and pick the DBmarlin tile
Name it, add teams if needed, and select an existing escalation policy or generate a basic one
Leave grouping on Default, finish setup, and copy the webhook URL ilert generates
2. Add the webhook in DBmarlin
In Settings → Integrations, find Webhook under Alert notification, click Edit, then Create
Enter a name such as "ilert webhook", the ilert webhook URL, your DBmarlin installation's reachable URL, and a Content-Type: application/json header
Paste both templates from the ilert docs, one for instance rules and one for host rules, then save and check that the webhook and the Webhook integration are enabled
3. Attach it to your alert rules
Set the webhook as Default to cover every alert rule, or add it to specific rules under Settings → Alert Rules
The DBmarlin alert source comes built into ilert and both templates are copy-paste, so setup is a few minutes of clicking rather than an integration project. Data flows one way, from DBmarlin to ilert.
On July 27, 2026, the Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force and rewrote the EU AI Act's timeline. The high-risk obligations that were due to apply on August 2, 2026, including Article 73 serious-incident reporting, now apply from December 2, 2027 for standalone high-risk systems (Annex III) and August 2, 2028 for AI embedded in regulated products (Annex I).
Not everything moved. Since August 2, 2026, Article 50 transparency obligations apply and the Commission can fine providers of general-purpose AI models, and the GPAI obligations in force since August 2025, including serious-incident reporting for systemic-risk models, stay in force.
Deferred, not cancelled. The extra 16 months are the window to build serious-incident reporting into your operations, not a reason to shelve it. Here is what changed, what didn't, and what your incident process needs to be able to do.
What the Digital Omnibus changed
The European Commission proposed the Digital Omnibus on AI on November 19, 2025, after it became clear the compliance ecosystem would not be ready for the original August 2026 deadline: harmonised standards from CEN-CENELEC were running late, conformity-assessment bodies weren't designated, and many member states had not stood up their market surveillance authorities. Parliament and Council reached political agreement on May 7, 2026, formally adopted the text in June, and published it in the Official Journal on July 24, 2026. It entered into force three days later, six days before the original deadline.
One detail matters for planning: the new dates are fixed, not conditional. The Commission's original proposal tied the delay to the readiness of standards and guidance, with 2027/2028 as backstops. The co-legislators replaced that with hard dates. Dr. Nils Rauer of Pinsent Masons called the agreement "a pragmatic step towards greater legal certainty", there is no scenario where the obligations land earlier, and no realistic one where they slip again.
The EU AI Act timeline, as it stands now
Feb 2, 2025 (in effect): Prohibited AI practices (Article 5); AI literacy duty (Article 4)
Aug 2, 2025 (in effect): Obligations for general-purpose AI (GPAI) model providers, incl. systemic-risk duties (Chapter V)
Aug 2, 2026 (in effect): Article 50 transparency obligations; Commission fining powers over GPAI providers (Article 101)
Dec 2, 2027: High-risk obligations for standalone Annex III systems, incl. Article 12 logging and Article 73 serious-incident reporting
Aug 2, 2028: High-risk obligations for AI embedded in regulated products (Annex I)
What applies in 2026 regardless of the delay
If you build or deploy AI systems in the EU, two things are live now:
Transparency (Article 50), since August 2, 2026. Users must be told when they are interacting with an AI system, and AI-generated or manipulated content must be labeled and machine-detectable. Not an incident duty, but the first AI Act obligation most engineering teams will actually be audited on.
GPAI enforcement, since August 2, 2026. The transparency, documentation, and copyright obligations for GPAI providers have applied since August 2025, what is new is the Commission's power to fine non-compliance, at up to 3% of global annual turnover or €15 million, whichever is higher. If you provide a GPAI model with systemic risk, serious-incident tracking and reporting is already expected under Article 55(1)(c), with the Code of Practice setting deadlines that mirror Article 73, plus a 5-day window for serious cybersecurity breaches.
Article 73: what serious-incident reporting actually requires
Article 73 is the AI Act's core incident-response obligation, and it is worth getting the numbers right, it is frequently misreported as a GDPR-style 72-hour rule. The actual windows for providers of high-risk AI systems:
Immediately after establishing a causal link between the AI system and the incident, or the reasonable likelihood of one, and no later than 15 days after becoming aware of a serious incident.
No later than 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure.
No later than 10 days in the event of a person's death.
A "serious incident" means an incident or malfunction that directly or indirectly leads to death or serious harm to health, a serious and irreversible disruption of critical infrastructure, an infringement of fundamental-rights obligations, or serious harm to property or the environment.
Three operational details engineers should note:
An incomplete initial report is explicitly allowed, followed by a complete one. The regulation expects you to notify while the investigation is still running, which means your reporting workflow can't depend on the postmortem being finished.
You must investigate, assess risk, and take corrective action, and you may not alter the AI system in a way that could affect the evaluation of the incident's causes before informing the authorities. Your evidence trail has to survive the response.
Deployers are in the loop too. Under Article 26(5), a deployer that identifies a serious incident must immediately inform the provider (then the importer/distributor and market surveillance authorities). Provider-deployer communication paths are part of compliance, not a nice-to-have.
The Commission has published draft guidance and a standard reporting template for Article 73; final versions are still pending. And the Act itself already de-duplicates: where a high-risk system falls under a sector regime with equivalent reporting duties, critical infrastructure under NIS2, medical devices under the MDR, Article 73(9)–(10) limit AI Act reporting to fundamental-rights incidents, with everything else routed through the sector rules. Translation: one well-built incident process serves multiple regulators.
Why build now, not in November 2027
The case for using the deferral rather than enjoying it:
The dates are now certain. Fixed deadlines removed the ambiguity that justified waiting.
The duties are process-heavy, not paperwork-heavy. Tamper-evident logging, cross-functional notification, evidence preservation, and reporting-while-investigating are operational muscles. Teams that add them late in 2027 will be scrambling to catch up; teams that run them now get a year of practice.
The same process already pays off elsewhere. NIS2's 24-hour early warning and 72-hour notification, GDPR's 72-hour breach window, and DORA's incident reporting all run on their own clocks, none of them was delayed. A single incident workflow with automatic timelines, role-based escalation, and audit-ready postmortems satisfies several regimes with one evidence set.
Article 73 readiness checklist
What your incident process has to be able to do before December 2027 and what pays off now under NIS2, DORA, and GDPR:
Classify at intake. Triage asks whether an incident could meet the Article 3(49) definition of "serious", so the AI Act clock is recognised on day one, not in the postmortem.
Timestamp awareness. The 2/10/15-day windows run from the moment you become aware. Capture it automatically, not from memory.
Preserve evidence before you fix. No changes to the AI system that could affect causal analysis until authorities are informed (Article 73(6)). Logs, model versions, and inputs must survive the response.
Report while investigating. An initial, incomplete report is allowed. The workflow can't wait for the root cause.
Wire the deployer → provider path. Deployers must inform providers immediately (Article 26(5)). Agree the channel and template in advance.
Notify legal and comms in parallel with engineering. The person who files the report is rarely the person fixing the system.
Map the regime per system. Know which clock applies: AI Act, NIS2, DORA, GDPR or whether a sector rule absorbs the AI Act duty under Article 73(9)–(10).
Export the timeline. Every notification is a document. Produce it from the record, not from recollection.
Article 73 readiness checklist
How ilert maps to the AI Act's incident duties
ilert doesn't make you AI Act compliant, no tool does. What it does is make the operational duties routine instead of heroic:
Audit-ready timelines (Article 12, Article 73(6)). Every alert, escalation, acknowledgment, and action is captured automatically in the incident timeline and can be exported, evidence that survives the incident without anyone writing it down mid-outage.
Reporting-grade speed (the 2/10/15-day windows).Multi-channel alerting, on-call schedules, and escalation policies mean awareness of an incident is measured in minutes. The hard part of Article 73 isn't the notification deadline, it's having the causal analysis and documentation ready. Automated timelines and AI-assisted postmortems produce that documentation as a by-product of response.
Cross-functional loops (Article 26(5), Article 73(1)). Playbooks notify engineering, legal, and comms in parallel, and status pages give stakeholders verified updates without pulling responders into meetings.
Monitoring-to-incident (Article 55(1)(c), Article 72). Threshold breaches from your monitoring stack, output drift, inference-error spikes, latency, open an incident automatically through ilert's alert sources, so post-market monitoring and incident tracking run on the same record.
EU-grade data handling. ilert is built and hosted in Germany, ISO 27001 certified, and GDPR-compliant, with AI inference kept in-region, so the tooling you use to respond to AI incidents doesn't create a new data-transfer problem.
Governance over autonomy. The AI Act's through-line is human oversight of AI. ilert AI SRE is built on the same principle: the agent investigates, correlates, and drafts, a responder reviews and decides what happens next. AI runs the investigation. You make the call.
See the whole flow, alerting, timeline, postmortem, in ilert's weekly live demo.
FAQ
Did the EU AI Act get delayed?
Partly. The Digital Omnibus on AI (Regulation (EU) 2026/1744, in force July 27, 2026) moved high-risk obligations to December 2, 2027 (Annex III) and August 2, 2028 (Annex I). GPAI obligations and Article 50 transparency kept their original dates.
What applies from August 2, 2026?
Article 50 transparency obligations, and the Commission's power to fine GPAI providers. GPAI obligations themselves, including serious-incident reporting for systemic-risk models, were already in force.
When does Article 73 serious-incident reporting apply?
It attaches to the high-risk regime: December 2, 2027 for standalone Annex III systems, August 2, 2028 for Annex I embedded systems. GPAI models with systemic risk already have a parallel reporting duty under Article 55(1)(c).
How fast must serious incidents be reported under the AI Act?
Immediately once a causal link (or its reasonable likelihood) is established, and no later than 15 days after awareness, 2 days for widespread infringements or critical-infrastructure disruption, 10 days for a death. Not 72 hours; that's GDPR.
Does the delay affect NIS2, DORA, or GDPR?
No. Those regimes and their reporting clocks are unchanged. (The wider Digital Omnibus package proposes amendments to GDPR and NIS2, but as of publication those are still under negotiation and are not law.) The AI Act itself routes most incidents involving sector-regulated systems through the sector rules (Article 73(9)–(10)), making one unified incident process the sensible hedge.
This article is practical incident-process guidance, not legal advice.
