Incident statuses reference
An incident’s status answers the question: where in the response are you? Atender exposes four statuses you can choose, plus one legacy value retained for historical updates.
The four user-selectable statuses
- Investigating — Yellow — You’re aware of the problem and looking into it. The cause isn’t clear yet.
- Identified — Orange — You’ve found the root cause. A fix is being prepared or deployed.
- Monitoring — Blue — A fix has been deployed. You’re watching the system to confirm stability.
- Resolved — Green — The incident is closed. The system is back to normal.
These four are the canonical lifecycle. When you create an incident, the initial status is one of investigating, identified, or monitoring — you can’t create one that’s already resolved.
How the suggested next status works
When you post an update, the composer suggests the logical next status:
- From Investigating → suggests Identified
- From Identified → suggests Monitoring
- From Monitoring → suggests Resolved
- From Resolved → no suggestion (the incident is closed)
The suggestion is a default; you can pick any of the four statuses regardless of the current state. You can move backward (e.g., from Monitoring back to Identified if a fix didn’t hold), and you can skip statuses (e.g., go straight from Investigating to Resolved if the issue was a transient false alarm).
The “update” status (legacy)
The database also stores a fifth status: update. It exists for historical updates that weren’t tied to a status transition. You don’t pick this in the UI. The status menu shown to responders only contains the four canonical values above. If you see update on an older incident, that’s an update posted before the redesign of the composer.
Status drives the public page
The status is what customers see on the public status page. Each value renders with a distinct color so visitors can scan the page quickly:
- Investigating / Identified — incident is active and unresolved. Shown at the top of the page.
- Monitoring — visible progress. Still under “Active” but signals a fix is in flight.
- Resolved — moves to the historical timeline section. No longer “active.”
How resolving works
Resolving an incident is inline in the composer — there’s no separate “Resolve” button. To resolve:
- Open the composer.
- Pick Resolved in the status menu.
- Write the final update (often a one-line summary: “All systems operational. Post-mortem to follow.”).
- Click Post update & resolve.
The server atomically posts the update, sets the incident’s status to resolved, and stamps resolvedAt. Subscribers get a final email.
Reopening a resolved incident
If something resurfaces after you’ve resolved, you can post a new update with a non-resolved status (e.g., back to Investigating). The incident moves back to active, and subscribers are notified of the new update.