Managing incidents
An incident is the thread you use to tell users what's happening during a problem — and to keep a record afterwards. Good incident communication is often what customers remember most.
Anatomy of an incident
| Field | Description |
|---|---|
| Title | A short, plain-language summary ("Elevated API errors"). |
| Impact | How bad it is — e.g. minor, major, critical. Drives the status-page indicator. |
| State | Where you are in the lifecycle (see below). |
| Updates | Timestamped comments as the situation evolves. |
| Affected components | The monitors/products involved. |
Lifecycle
An incident moves through states as you post updates, and is either open or closed:
INVESTIGATING → IDENTIFIED → MONITORING → RESOLVED
- Investigating — you're aware and looking into it.
- Identified — you know the cause.
- Monitoring — a fix is applied and you're watching.
- Resolved — the incident is closed.
Posting an incident
- Console → Incidents → New.
- Set a title and impact, and select affected components.
- Write the first update describing what users are seeing.
- Post further updates as you progress; mark Resolved when recovered.
Good practice
- Post the first update fast, even if it's just "we're investigating".
- Describe user impact, not internal jargon.
- Keep a steady cadence of updates during a major incident.
- Write a short closing summary when resolved.
Tip
Speed up repetitive wording with incident templates and let AI draft the first update for you.