AI-First Incident Management. With Privacy in Mind.

Imagine incidents resolved through insights, not manual investigations.

‍

Picture an incident management future where you're never alone during critical alerts. Imagine your best engineer always available, tirelessly investigating issues, analyzing logs, correlating metrics, checking recent code changes, and delivering actionable insights, instantly. Today, ilert is stepping boldly into this future with our first intelligent agent: ilert Responder.

Why AI-first?

Incident management is evolving rapidly. Systems grow complex, alert volumes surge, and pressure on teams intensifies. SREs often find themselves overwhelmed by noise, urgently navigating logs, metrics, and dashboards to uncover root causes.

‍

At ilert, we've been pioneering AI in incident management for over three years, launching intelligent alert grouping, automated post-mortem creation, and more. ilert Responder is not a beginning, but a leap forward, building on years of experience, foundational work, and customer feedback.

‍

We're laser-focused on helping companies significantly reduce Mean Time to Resolution (MTTR). Every decision, every feature we develop revolves around one question: How does this contribute to lowering MTTR? With GenAI and agentic systems, we see transformative potential to contribute to this goal. We’re betting on a future where you're only paged about an incident if AI can't autonomously resolve it first. Imagine no more waking up at 3 a.m. just to restart a service or roll back a deployment.

‍

That’s why we’re committed to becoming an AI-first platform, embedding artificial intelligence at the heart of everything we do. This isn't just adding AI as a feature; it's fundamentally reimagining incident response for the better.

Meet ilert Responder: Your 24/7 incident co-pilot

ilert Responder is your trusted teammate and is built directly into the ilert platform. It:

‍

• Connects directly with your observability stack, your cloud infrastructure, and code repository.
• Analyzes incidents in real-time using various data sources, pinpointing root causes.
• Provides clear, prioritized recommendations for remediation.

‍

Interact seamlessly via a chat-based interface, ask questions, share context, and receive guidance precisely when you need it. Every insight from ilert Responder is clear, actionable, backed up with supporting data, even under pressure.

‍

Under the hood, we’re using the MCP (Model-Context Protocol) to connect the ilert Responder agent with your tools and infrastructure. MCP is to AI what HTTP is to the web – a standardized protocol for connecting LLM-based agents to the systems where real data lives. It solves two key challenges: the limited, outdated knowledge and lack of context of LLMs, and the complexity of maintaining custom integration layers between AI apps and external data sources.

‍

With MCP, ilert Responder can securely and contextually interact with tools like Grafana, Prometheus, GitHub and Kubernetes – fetching logs, metrics, deployment data, code changes, and more in real time. We've built a scalable, multi-tenant architecture around MCP that allows us to easily add new data sources (MCP servers), continuously expanding Responder’s investigative capabilities with every integration.

See the ilert Responder in action

‍

Introducing Agentic Incident Management

‍

ilert Responder marks the start of what we call Agentic Incident Management. Here, intelligent agents:

‍

• Reason and investigate like seasoned engineers.
• Learn from each interaction, growing continuously smarter.
• Work alongside humans transparently, always with clear oversight.

‍

By default, the new ilert Responder operates in read-only mode and provides you with recommendations for faster resolution. It doesn't replace your on-call team but augments it.

Join the ilert Agentic Incident Response beta program

‍

We're inviting innovative teams to join our Beta program, granting early access to ilert Responder. Beta testers will:

‍

• Directly shape future capabilities.
• Enjoy early benefits and competitive advantages.
• Lead their industries into the future of AI-powered incident management.

‍

Interested? Email us at support@ilert.com and become a pioneer in the AI-first incident response revolution.

‍

AI-first incident management – for everyone

AI features have been an integrated part of ilert for a few years now. With this next step, AI features are no longer reserved for premium plans or add-ons; they're foundational. 

‍

We have already introduced some significant changes in our pricing. While in the Beta phase, ilert AI Responder is available at no additional cost. But that's not all. You will notice that we’re discontinuing our AIOps add-on and making AI features such as intelligent alert grouping available in the Scale plan. Even Free ilert customers now have access to ilert AI features. 

‍

Soon, all ilert customers will have flexible AI credits to unlock advanced capabilities – from ilert Responder to ilert postmortem creator. Details on our transparent, credit-based pricing model will follow shortly. Stay tuned to our blog and newsletter.

Privacy-first, always

Privacy and security of your data remain the highest priority for us. We champion AI-first to accelerate incident resolution, embedding Privacy First with data sovereignty, end-to-end encryption, region-specific AI-processing, and GDPR compliance. From day one, we’re building intelligent systems that are as protective of confidentiality as they are innovative. ilert AI Responder is built on this basis. 

‍

For ilert AI, we use foundational models hosted by AWS, Microsoft Azure, or OpenAI, depending on your location. For EU customers, all AI processing happens within Europe using AWS or Microsoft infrastructure – no data leaves the EU, and no personal or sensitive information is sent to OpenAI’s global endpoints. Customers outside the EU may use OpenAI or AWS, always under strict access controls and encryption at rest and in transit.

‍

Moreover, we only use alert incident-related data and don’t share personal or user-level performance data with external AI models. We also don't use your data to train models and have opted out of data training with all of our LLM providers. 

‍

Learn more about our security and privacy commitment in the Q&A section.

‍

We're entering a new era in incident response, one where AI doesn't replace SREs, it elevates them. ilert Responder is just the beginning. The future is collaborative, intelligent, and human-centered. Let's build it together.

‍

‍

The ilert mobile app is primarily used by responders to receive notifications about critical alerts, react to them on the go, and check their current on-call status. It has various capabilities, including critical notifications via push, quick actions for alerts, and critical alert settings. The app enables responders to view their current on-call shifts and escalation policies, take on-call shifts from somebody else, and create coverage requests to ask for on-call shift handover from a colleague. The latter is a new feature of ilert that has proven to be very useful for a communication tool between users, and this post is taking a deeper dive into the development of the feature and the challenges we faced developing it.

Why were coverage requests introduced?

Since we introduced on-call schedules, users have been able to create overrides—special shifts that take priority over regular ones. An override lets you assign another user to take over on-call duty, either for a full shift or just part of it. Overrides don’t have to follow existing shifts—they can be created for any time period, even outside of configured shifts.

‍

Later on, the "Take on-call" feature was introduced, which is the opposite of overriding my shifts. Both methods create overrides, but neither method ensures that the other user gets notified of any action taken on their on-call shifts. Furthermore, creating overrides for other users was giving them responsibility they eventually weren't aware of, and this could be critical.

‍

The solution for this problem was to introduce a flow of asking another user to take over specific on-call duties, resulting in a short communication stream of requesting coverage.

Designing the coverage request REST API

The general flow of a coverage request should be:

‍

1. User A creates a coverage request, asking User B to (partially) take over one or multiple shifts

2. User B gets notified, either accepts or declines the coverage request

3. User A gets notified of the action that User B decided to choose

‍

‍

We needed to design the API around a coverage request entity, which had to have at least the following fields:

- sender

- receiver

- shifts

‍

Additionally, we added a message field to give users an option to communicate additional details for their request. For the user interface, we also provided the current state and the createdAt date string, which are read-only properties. When the user declines the coverage request, some communication back may be useful too, handled by giving the user the ability to add a declineComment. Lastly, to show multiple coverage requests in a list view and apply meaningful filters, we used the state field in combination with an `expired` state calculated in the frontend. A coverage request is considered expired when the last shift it covers has ended.

‍

Beyond the classic Create and Read operations on the coverage request entity, we needed specific endpoints to perform actions: accept, decline, and cancel. Update and Delete operations are not part of the flow right now and won't be implemented.

From mockup to polished UI

There are no significant differences between the mockup and the final version of the coverage request creation view. The styles have been adjusted, and an additional timezone information box has been included. The final versions of the list view and the detail view look like this:

‍

Communication is key

A general goal of this feature is to motivate users to see and respond to coverage requests as early as possible, as on-call shifts are always bound to time and can sometimes be on short notice. Another goal is to let all relevant communication stay in the ilert mobile app, eliminating the need to switch between tools. To achieve this, several means of communication are introduced.

Push notifications

Whenever an action related to a coverage request is taken, a push notification is sent to the relevant person.

• Coverage request created: receiver gets notified
• Coverage request accepted/declined: sender gets notified
• Coverage request cancelled: receiver gets notified

‍

But what if the receiver doesn't have a mobile app?

‍

Email

ilert checks if any of the relevant users don't have at least one registered push notification token (unique ID from a user on a device, used by ilert to route push notifications). If that is the case, ilert sends out an email to the user’s primary email, containing information about the coverage request.

‍

In-app badge

Sometimes push notifications get dismissed by accident, without recognising the content (and possibly swiping away a time-critical coverage request). To provide more presence in the app, a small red circle (badge) is added at the top left of the menu icon in each list view. It indicates whether there is one or more pending coverage requests for review. Additionally, the main menu item shows a count of all pending requests at any time.

Provide filters, but keep the UI clean

Giving the user the ability to filter coverage requests in the list view is necessary. An obvious one is a filter for Received and Sent requests. Another important but tricky filter is for relevant requests only. That means any expired and not pending requests are filtered out by default. But as we already have the Received/Sent toggle, another toggle for Current/All would've cluttered the UI too much.

‍

One idea was to introduce a filter toolbar (similar to the one implemented on the alert list), but the idea was discarded as it would've been the only filter at the time of release (which would've looked odd). Another idea was to choose the default: only show requests in state Pending, and let the user access all via a button click. Ultimately, we settled on this solution for its simplicity and ease of use.

‍

Every day usage reveals papercuts

After the release of the feature, the ilert team started using the feature internally as well, and quickly recognized one flaw of the feature. When acting on a coverage request (accept, decline, or cancel), the coverage request would instantly disappear from the list without giving a clear confirmation of the coverage request's change of state. 

‍

Two improvements were put in place:

• Stay on the detail view after an action happens to see the updated state of the request
• Keep relevant coverage requests in the list view for 24 more hours after performing an action

‍

The latter wasn't the case before, because the list was initially built upon the state field, meaning it would instantly disappear from the list upon acceptance. A click on past requests was needed to view the just-accepted request. Therefore, an additional query parameter was defined and included in the API, enabling the frontend to specify a past creation date. The response also included all coverage requests—no matter their status—from the given creation date up to now. Now users can see all pending coverage requests, plus recently accepted/declined/cancelled ones (in the last 24 hours).

‍

Haven't  installed the ilert app yet? Give it a try! Download the app for Android or iOS.

We’re excited to share that Rollbar is now part of the ilert integration catalog! This new technical partnership allows software teams to detect application errors in real time with Rollbar and instantly respond using ilert’s powerful alerting and incident management features.

What is Rollbar?

Rollbar is a comprehensive, real-time error monitoring and debugging platform designed to help development teams detect, diagnose, and resolve issues faster—before they impact users. By providing deep visibility into application errors across the entire software lifecycle, Rollbar empowers teams to ship higher-quality code with greater confidence. With clients like CircleCI, Twilio, Babbel, and Salesforce, Rollbar is trusted by teams that prioritize reliability and seamless user experience.

‍

At its core, Rollbar gives you deep visibility into your application’s health by capturing errors as they happen. Whether it's a backend exception or a frontend crash, Rollbar collects detailed metadata—including stack traces, request parameters, and user data—so developers can fix bugs quickly and confidently.

‍

Key highlights of Rollbar:

‍

• Real-time monitoring: Instantly detect and visualize errors.
• Intelligent grouping: Reduce noise using machine learning-based error clustering.
• Comprehensive context: Investigate errors with full context, from local variables to affected users.
• Enterprise-ready: Scales with your infrastructure and offers strong security and integrations.

How you can benefit from the Rollbar and ilert integration

With this new integration, Rollbar alerts can now trigger events in ilert automatically—enabling rapid, targeted incident response across your engineering and SRE teams.

‍

Here’s how your team benefits:

‍

• Deploy with confidence: Get notified instantly when a new deployment introduces an error. You can roll back quickly or fix forward without waiting for user complaints.
• Bridge the gap between Dev and Ops: SREs and developers can collaborate more efficiently, as ilert routes Rollbar alerts to the right on-call engineer using your preferred notification channels—phone, SMS, push, Microsoft Teams, and more.
• Centralized approach for faster root cause analysis: ilert enables teams to receive alerts from various alert sources, which helps to expedite root cause analysis. ilert as a central dispatcher can correlate Rollbar alerts with alerts from other sources to help teams resolve incidents faster.

How to Connect Rollbar and ilert

Getting started is easy. To integrate Rollbar with ilert, follow our step-by-step guide. It takes just a few minutes to:

‍

1. Create an alert source in ilert.
2. Generate an endpoint URL.
3. Add the webhook in your Rollbar settings.

‍

Once connected, Rollbar will send error notifications to ilert, where you can manage them using your existing on-call schedules, escalation policies, and alerting preferences.