> For the complete documentation index, see [llms.txt](https://docs.ilert.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ilert.com/incidents-and-status-pages/incidents.md). # 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](/alerting/working-with-alerts.md) 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](/incidents-and-status-pages/status-updates.md), which is always a deliberate act — so you can coordinate first and decide what to say second. {% hint style="info" %} What ilert used to call an "incident" is now a [**status update**](/incidents-and-status-pages/status-updates.md). Existing history was migrated; **Incident** now means the coordination record on this page. {% endhint %} ## 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](/incidents-and-status-pages/incidents/incident-channels.md) 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](/incidents-and-status-pages/status-updates.md). | 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](/incidents-and-status-pages/incidents/incident-channels.md) and [conference bridge](/incidents-and-status-pages/incidents/conference-bridges.md), each of which can be created from this row. * **Summary** — an internal description of what is known so far. * **Affected services** — the [services](/incidents-and-status-pages/services.md) this is impacting, each with an impact level. * **Responders** and **Subscribers** — the people [working it and watching it](/incidents-and-status-pages/incidents/responders-and-paging.md). * **Linked alerts** — the [alerts](/incidents-and-status-pages/incidents/declare-an-incident.md#linking-alerts-to-an-incident) that led here. The right-hand panel has three tabs: the [**Timeline**](/incidents-and-status-pages/incidents/incident-timeline-and-comments.md), 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 incidentOpen one from scratch or from an alert, and link the alerts that led to it.Declare an incident
Responders and pagingBring in the people you need, and see who has actually joined.Responders and paging
Incident timeline and commentsThe running record of what happened, and the notes you add to it.Incident timeline and comments
Incident channelsA Slack, Microsoft Teams, or Google Chat channel of the incident's own.Incident channels
Conference bridgesA live call attached to the incident, for when typing is too slow.Conference bridges
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.ilert.com/incidents-and-status-pages/incidents.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.