Declare an incident

Declare an incident from scratch or from an alert, and link the alerts that led to it.

An incident starts one of two ways: from scratch, or from an alert that has revealed something bigger. Either way it opens in the Declared status, ready to coordinate.

Declare from scratch

Use this when nothing fired — a customer report, a third-party outage, a security event, or an exercise.

1

Open the dialog

Go to Incidents and click Declare incident.

2

Describe what is happening

Only Title and Severity are required, and severity is already filled in.

Field	Required	What it does
Templates	No	Fills Title, Summary, and Severity from a saved incident template. It never ticks Create incident channel for you
Title	Yes	A short internal description. Never shown publicly
Severity	Yes	The business impact. Defaults to SEV3
Summary	No	What is known so far. ilert AI can draft it from the title
Affected services	No	The services being impacted, each with an impact level. ilert suggests candidates
Create incident channel	No	Opens a chat channel with the incident

Choosing SEV1 or SEV2 ticks Create incident channel for you. It is a default, not a rule — untick it and it stays unticked, and applying a template never changes it either way.

3

Declare it

Click Declare incident. It opens in the incident view, where you can page responders and start the timeline.

Declare from an alert

When an alert turns out to be the tip of something, open it and click Declare incident. The dialog arrives pre-filled:

• the title comes from the alert title;
• the summary is drafted from the alert details;
• affected services are pre-selected from the alert's related services, and you set each impact level;
• the alert is linked, and its responders become responders on the incident.

An escalation still running on that alert is continued on the incident rather than dropped, so nobody who was already being paged is lost. The dialog says so — Current escalation will be continued — and you can turn it off before declaring.

This is the one path that carries an escalation across. Linking an alert to an incident that already exists does not: linking accepts the alert, and accepting stops escalation.

Linking alerts to an incident

Linking records which alerts belong to this incident, so the incident becomes the one place to work and the alerts stop demanding attention of their own.

The alert you declare from is linked for you. To add more, open the incident and click Link alert in the Linked alerts section.

Linking an alert:

• accepts it, if it was still pending — which is what stops its escalation, because an accepted alert has an owner;
• adds its responders to the incident;
• sets its status to Linked, in the alerts list and on the alert itself.

Linked replaces the status you would otherwise see, rather than sitting beside it. Underneath, the alert is Accepted — which is why escalation stops the moment you link — and the incident's own Linked alerts section shows that underlying status next to the time it was linked.

An alert belongs to at most one incident. Linking one that is already linked fails with an error rather than moving it.

Unlinking

Click Unlink next to the alert. It goes back to showing Accepted — the status it has had all along, behind the Linked label — and nothing else changes. In particular its escalation does not restart, because accepting it was what stopped that. If it still needs someone, re-trigger escalation on the alert itself.

What resolving does, and does not do

Resolving an incident does not resolve its alerts behind your back. It opens the Before you resolve checklist, where closing each linked alert is offered and ticked by default. Untick one and it stays open, still accepted, still yours to deal with.

Affected services and impact levels

Affected services record which business capabilities are being hit, each at an impact level such as Degraded or Major outage.

Setting them changes ilert internally — the incident, the lists, the internal dashboards. It changes nothing your customers see.

A service's public status moves only when you post a status update. That gap is deliberate: it is what lets you mark something degraded internally at 03:00 and decide what to tell customers at 03:20.