For the complete documentation index, see llms.txt. This page is also available as Markdown.

Incidents

An incident is the coordination record above your alerts: who is responding, what is known, what has been tried, and what customers have been told.

An incident is where a response is organized. You link the alerts that led to it, page the people you need, keep a timeline of what was found and decided, and — separately, and only when you choose — tell your customers.

Where an alert is a machine-generated signal that pages whoever is on call, an incident is declared by a person. Nothing has to have fired first: declare one whenever a response needs coordinating, including for a customer report, a third-party outage, or an exercise.

Alerts, incidents, and status updates

ilert keeps the technical signal, the internal coordination, and the public message as three separate objects. Confusing them is the commonest mistake in incident response, and the reason the separation exists.

Object
Created by
Audience
Purpose

Alert

A monitoring tool, automatically

On-call responders

A technical signal that pages the right people

Incident

A person, from scratch or from an alert

Your response team, internally

The coordination record that organizes the response

Status update

A person, from an incident

Customers and stakeholders, publicly

The message shown on your status pages

An incident is internal. Its title, summary, severity, and timeline are never shown to customers. Nothing reaches a status page until you post a status update, which is always a deliberate act — so you can coordinate first and decide what to say second.

What ilert used to call an "incident" is now a status update. Existing history was migrated; Incident now means the coordination record on this page.

Severity

Severity states business impact. There are five fixed levels, and new incidents start at SEV3.

Severity
Meaning

SEV1

Critical — major service disruption, highest priority

SEV2

High — significant impact, urgent response

SEV3

Medium — limited impact, partial degradation

SEV4

Low — minor degradation, no service impact

SEV5

Informational

Severity is more than a label: declaring at SEV1 or SEV2 turns on incident channel creation in the declare dialog by default, on the assumption that an incident that serious wants a room.

Status

Status says where the incident is in its life, and is separate from the public status on a status update.

Status
Meaning

Declared

Just created

Investigating

The team is looking for the cause

Identified

The cause is known and a fix is underway

Monitoring

A fix is in place and the team is watching

Resolved

The impact has ended and the incident is closed

The incidents list

Incidents in the top navigation lists every incident your teams own, filtered by service, status, severity, or creation date. Each row carries the severity, the INC- number and title, affected services, how long it has been open, how many paged responders have joined, the number of linked alerts, and the status.

The ilert incidents list, with columns for severity, incident number and title, affected services, duration, responders joined out of paged, linked alerts, and status.
The responders column reads joined out of paged — 1/3 means three people were paged and one has joined.

The incident view

Opening an incident puts the whole response on one screen.

An ilert incident view showing the Join, Page and Post status update buttons, an attribute row with severity, status, declared time, declared by, duration, incident channel and conference bridge, a prompt to run an AI investigation, the summary, and the Timeline, Status updates and Investigations tabs.
Everything above the fold: what this is, who owns it, and what has happened.

The header carries the three actions you take most: Join to add yourself as a responder, Page to bring others in, and Post status update to say something publicly.

Below it:

  • Attribute row — severity and status, both editable here; when it was declared and by whom; how long it has been open; the incident channel and conference bridge, each of which can be created from this row.

  • Summary — an internal description of what is known so far.

  • Affected services — the services this is impacting, each with an impact level.

  • Responders and Subscribers — the people working it and watching it.

  • Linked alerts — the alerts that led here.

The right-hand panel has three tabs: the Timeline, the Status updates posted from this incident, and any Investigations an AI agent has run against it.

The view also suggests a next step in context. On a freshly declared incident that is Run an AI investigation, which sets an agent to work across the linked alerts and affected services.

Resolving an incident

Set the status to Resolved and ilert opens a Before you resolve checklist of everything the incident is still holding open. This exists because an incident owns things that do not close themselves, and closing the record without landing them leaves alerts open and services showing degraded.

Section
What it offers
Default

Affected services

Set each service back to Operational. A service still affected by another open incident is left unchecked and labelled as such

On

Linked alerts

Resolve & close this alert for each alert this incident owns. Reversible — an alert can be re-triggered if the problem returns

On

Final status update

Publish a Resolved update so status pages and subscribers hear the all-clear

On, but only if this incident has already posted one

Postmortem

Have ilert AI draft one from the timeline, linked alerts, and correlated deployments

On when eligible

Active escalation

Tells you how many responders are still being paged, and that resolving stops it

Choose Resolve incident to land what is ticked, or Resolve without these to close the record alone. If there is nothing to land, the incident resolves without a dialog.

In this section

Last updated

Was this helpful?