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.
This September, we hosted a few of our customers at the ilert headquarters in Cologne. The plan was to share where we're heading, have real-life conversations, and give them more room to ask us questions and share their thoughts.
One part of the day was a discussion about on-call culture with some of the greatest minds in SRE (source: they chose ilert as their incident management tool). We asked our customers: what are your top practices for on-call? Everyone shared their thoughts and voted for the ones they agreed with most. We've kept the answers in their own words.
1. Be ready and reachable
The worst thing that can happen when an alert fires is that your team can't reach you. So the most practical answers of the day went straight to the top:
“Have the ilert mobile app installed”
“Keep your phone charged and reachable”
It sounds obvious, and it is. But being reachable is the foundation everything else in on-call depends on. If an alert can’t reach the right person, nothing else in the response matters. With the ilert app, critical alerts get through to you, even when your phone is on Do Not Disturb.
2. Build a positive team culture
The group had a lot to say about team culture and mindset. The consensus was that a positive mindset matters:
"Good team spirit helps you get through difficult situations."
"Be kind, stay cool, go on."
"Always keep cool 😎"
"Blameless."
Many mentioned some version of "be good to each other." Tools make sure you get paged, but people are what get you through the night. Being blameless matters most once the incident is over: the postmortem should be about the system, not about who pushed the button.
This is the practice teams most often get wrong, and the group had strong opinions on it:
"If a page can't be acted on at 3am, it shouldn't page."
"Separate product support from SLA incidents: only report and resolve SLA-relevant incidents."
"Empower your support agents to solve the culprit of alerts rather than teaching them how to snooze in less than 3 seconds."
We had a laugh about the snooze speedrun, but the point is serious. Every alert should be something a person can act on. If it isn't, it needs to be tuned, grouped or moved to business hours.
4. Communicate openly and make escalation easy
When an incident hits, how you talk about it matters almost as much as how you fix it. The group agreed on two things:
"Keep the communication public (company-wide), not in private channels or chats."
"Fallbacks and easy ways to escalate."
Incident context gets lost in DMs. When updates go into a shared channel or onto a status page, the next responder, your support team and your manager can all see what's going on without asking. Fallbacks mean nobody becomes a single point of failure. If the first responder doesn't acknowledge an alert, an escalation policy should do the chasing so no human has to.
5. Make on-call visible to management
One practice was aimed less at the engineers on call and more at the people who plan their time:
"Make capacity going into on-call and support duties transparent to management – nothing comes for free."
It wasn't the loudest practice of the day, but it may be the most important sentence. On-call is work. It uses up hours, focus and sleep. If it doesn't show up in capacity planning, it will show up later as burnout.
Bonus: It was always DNS
It didn't top the list. Probably not because anyone disagreed, but because nobody needed convincing.
What we're taking home
When you bring together the people who run on-call teams, you might expect a list of tools and processes. Instead, the practices that rose to the top were "charge your phone" and "be kind." The basics still win. The teams that get on-call right are the ones that make it predictable, actionable and humane, and that takes support from the whole organization, not just whoever is holding the pager tonight.
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.
