Incident statuses reference
An incident’s status answers the question: where in the response are you? Atender uses one status lifecycle for ordinary incidents and a separate set of labels for planned maintenance.
Ordinary incident 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 outage lifecycle. When you create an ordinary incident, the initial status is one of investigating, identified, or monitoring — you can’t create one that’s already resolved.
Planned-maintenance statuses
Planned maintenance uses its own status labels so customers can tell the difference between an unexpected outage and scheduled work:
- Scheduled — The maintenance window has been announced, but the work has not started yet.
- In progress — The maintenance window has started, or the maintenance has been opened by an agent.
- Completed — The maintenance is finished. This is the resolved state label for maintenance.
Use Scheduled before the maintenance window, In progress once the work starts, and Completed when the work is done.
How the suggested next status works
When you post an update on an ordinary incident, 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 ordinary incident 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 legacy 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 current lifecycle 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.”
- Scheduled — planned maintenance has been announced, but the window has not started.
- In progress — planned maintenance is currently happening.
- Completed — planned maintenance is finished and shown as historical.
How resolving works
Resolving an ordinary 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.
For planned maintenance, the resolved state is labeled Completed instead of Resolved.
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.