Incident management
Get started with incidents
Use incidents to track downtime, SSL problems, manual reports, ownership, comments, status changes, and recovery. It explains how incidents are created, assigned, discussed, updated, and closed so responders can keep the timeline clear from detection through recovery.
How incidents are managed
Incidents collect the operational record for a service problem. Each incident has a title, description, severity, status, trigger type, detected time, linked service, assignees, and a timeline of system and user updates.
- Automatic incidents are created when monitor checks confirm downtime after the configured failure threshold.
- SSL incidents are created when SSL verification or expiry checks detect a certificate problem.
- Manual incidents are created by a user when a service issue needs to be tracked even if the monitor has not opened one automatically.
- Incidents can be assigned to team members, commented on, shared, and moved through the response status flow.
Use the incident list
Open Incidents to see current and historical incidents. The list supports search and filters so you can find work by website, severity, status, trigger type, mode, assignee, creator, or detected date.
Filter before handoff
Use Assigned To and Status filters during handoff so unresolved work does not get buried under closed incidents.
Incident status flow
| Status | Use it when |
|---|---|
| Open | The incident exists and needs attention. |
| Investigating | A responder is actively looking for the cause. |
| Identified | The cause is known and a fix is planned or underway. |
| Monitoring | A fix has been applied and the team is watching for stability. |
| Resolved | The customer-impacting issue is fixed. |
| Closed | The incident record is complete. |