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.
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.
Bleemeo monitoring now connects natively to ilert, linking threshold detection to on-call management and alerting. DevOps, SRE, and IT operations teams get a direct path from a breached threshold to the phone of the engineer who can fix it, and back to a clean slate once the problem is gone.
What is Bleemeo?
Bleemeo is a cloud monitoring platform that covers servers, Docker containers, Kubernetes clusters, AWS and Azure resources, VMware environments, and SNMP network devices, all from one SaaS console. It also handles uptime checks, application performance, and logs, so teams can watch their infrastructure and the services running on it in one place.
Data collection runs through Glouton, Bleemeo's open-source agent. Alerting rules are threshold-based with separate warning and critical levels, and teams that want finer control can express conditions in PromQL.
Why connect Bleemeo to ilert?
Bleemeo is good at detecting that something is wrong. What happens next, who gets woken up, and what follows if they don't answer, is where ilert takes over.
Paging is where ilert starts, not where it ends. The same alert can become a declared incident with its own channel and incident commander, a status page update for customers, and a postmortem once it's closed.
Two details matter day to day. First, resolution is automatic: when the issue clears in Bleemeo, ilert closes the corresponding alert, so what's open reflects the real state of your systems instead of a backlog someone has to tidy up. Second, grouping happens per monitored metric, or per agent for agent-level events. Repeated notifications about the same problem update the existing entry rather than piling up new ones, so a struggling host wakes you once, not fifty times.
Two European platforms, one alerting chain
Bleemeo is a French company, founded in Toulouse in 2015, with metrics and logs stored in the EU. ilert is a German company in Cologne, hosted in EU data centres and ISO 27001 certified. For teams working under GDPR, NIS2, or DORA scrutiny, that means a monitoring-to-paging chain where both counterparties contract under European law, one fewer subprocessor conversation in the security review.
Set up the integration in three steps
1. In ilert:
Go to Alert sources and create a new one
Search for Bleemeo and select it
Give it a name, assign teams, choose an escalation policy, and set your grouping preference
Finish setup and copy the integration key
2. In Bleemeo:
Open Administration → Integrations and click Add Integration
Select ilert, paste the key, and add a descriptive name such as "Production On-Call"
3. Route your alerts:
Go to Notifications, create a new rule or edit an existing one
In the Targets step, select your ilert integration
Because ilert ships a purpose-built source for Bleemeo, there is no field mapping to configure. Alerts flow inbound, from Bleemeo into ilert, and setup takes a few minutes end to end.
