What Is an Incident?
An incident is a time-bounded event that affects one or more components on your status page. It has a title, a list of affected components, a severity, and a chronological log of timestamped updates. Incidents are visible on the status page while active and archived in the incident history when resolved.
Creating an Incident
- Go to Admin → Content → Status → Incidents.
- Click New Incident.
- Fill in the initial fields:
| Field | Required | Notes |
|---|---|---|
| Title | Yes | Short, factual description (e.g. "Email Delivery Delays") |
| Affected Components | Yes | Select one or more components from the list |
| Severity | Yes | Investigating / Identified / Monitoring / Resolved |
| Initial Update Body | Yes | First status message visible to clients |
| Component Status Override | No | Optionally update affected component statuses at the same time |
- Click Save. The incident appears at the top of
/statusimmediately.
[!TIP] Create an incident as soon as you confirm something is wrong, even if you do not yet know the cause. An "Investigating" status with a brief "We are aware of reports of email delivery delays and are investigating" message is far better than silence.
Posting Subsequent Updates
Each update you post is appended to the incident's timeline. Clients see all updates in chronological order.
To add an update:
- Open the incident from Admin → Content → Status → Incidents.
- Click Post Update.
- Write the update body.
- Change the severity if appropriate (e.g. from Investigating to Identified).
- Optionally update the status of affected components.
- Click Save.
Incident Severity Stages
| Severity | Meaning |
|---|---|
| Investigating | You are aware of the issue but do not yet have a cause |
| Identified | Root cause has been found; fix is in progress |
| Monitoring | Fix applied; monitoring to confirm resolution |
| Resolved | Issue fully resolved; all components restored |
Progress through these stages as your investigation advances. Update the severity with each post.
Resolving an Incident
When the issue is fully resolved:
- Post a final update describing what was fixed.
- Set severity to Resolved.
- Set all affected component statuses back to Operational.
- Save.
The incident moves from the active section to the incident history on the status page. The history is paginated and publicly visible.
[!IMPORTANT] Resolving an incident does not automatically reset component statuses. You must manually set each affected component back to Operational either within the incident update form or by editing the component directly.
Scheduled Maintenance as an Incident
Planned maintenance windows should be created as incidents with severity set to Under Maintenance (or using the Scheduled Maintenance incident type, if available). This approach:
- Notifies clients via the status page before the window begins
- Provides a place to post progress updates during the window
- Creates a permanent record in the incident history
Set the incident's scheduled_for date when creating it. The incident appears on the status page with a "Scheduled Maintenance" label and the planned start time.
Incident History
All resolved incidents remain in the incident history section at the bottom of /status. This gives clients a record of past events and demonstrates transparency about historical reliability. Incidents cannot be hidden from the history after resolution, only deleted (which requires admin password confirmation).