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 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.

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

Declare an incident

Open one from scratch or from an alert, and link the alerts that led to it.

Responders and paging

Bring in the people you need, and see who has actually joined.

Incident timeline and comments

The running record of what happened, and the notes you add to it.

Incident channels

A Slack, Microsoft Teams, or Google Chat channel of the incident's own.

Conference bridges

A live call attached to the incident, for when typing is too slow.