How do I manage incidents on my status page?
Create and manage incidents with severity levels, timeline updates, and affected component tracking.
Incidents let you communicate service disruptions to your users in a structured, transparent way. Each incident has a severity level, a live status timeline, and tracks which components are affected.
This feature is currently in development.
Overview
When something goes wrong, an incident gives you a place to post updates as the situation evolves. Rather than asking users to check back repeatedly, each update is timestamped and visible on your status page in chronological order - and if subscribers are enabled, updates go out by email automatically.
Incidents are designed to be low-friction to create so your team can focus on resolving the problem rather than managing communications. A single incident record captures everything: the severity, the affected components, the timeline of updates, and the resolution - all in one place that users can reference.
Incident Severity Levels
Incidents will support three severity levels:
| Severity | When to use |
|---|---|
| Minor | Partial degradation affecting some users or non-critical functions |
| Major | Significant disruption affecting many users or a critical function |
| Critical | Full outage of a core service |
Severity is visible on the status page and in notification emails so users can quickly gauge how seriously they should be concerned.
Choosing the Right Severity
Minor is appropriate when the impact is limited in scope. Examples: a secondary reporting endpoint is returning slow responses, a non-critical integration is failing for a subset of users, or a feature that is not on the core path is temporarily unavailable. Users can still accomplish their primary goals, but they may notice degraded performance in specific areas.
Major should be used when a significant portion of users are affected, or when a core function of your service is impaired but not completely unavailable. Examples: login is succeeding but takes much longer than normal, the API is returning intermittent errors under load, or a primary feature is broken for a specific region or customer segment. Users are likely to contact support or seek alternatives.
Critical is reserved for full or near-full outages of a core service. Examples: your API is returning errors for all requests, your application is completely unreachable, or a data processing pipeline has stopped entirely. Users cannot complete their primary workflows and need to know immediately.
You can update the severity of an incident as the situation evolves. If an issue initially appears minor but expands in scope, changing the severity ensures the status page accurately reflects the current impact.
Incident Status Timeline
Each incident moves through a standard set of statuses as your team works through the problem:
- Investigating - you’re aware of the issue and actively looking into it
- Identified - you’ve found the root cause and are working on a fix
- Monitoring - a fix has been applied and you’re watching to confirm stability
- Resolved - the incident is over and all systems are back to normal
Each status transition creates a new timestamped entry in the incident timeline. Visitors can see the full history of how the incident evolved from initial detection to resolution.
What to Communicate at Each Stage
Investigating: Post this update as soon as you are aware of the issue, even if you do not yet know the cause. Users benefit from knowing that the team is aware and actively working on the problem. Include what symptoms you are seeing and which components appear to be affected. A prompt Investigating update prevents a flood of support requests asking whether the team is aware of the issue.
Identified: When you have a confirmed root cause, update the incident to Identified and explain what was found. You do not need to share full technical details, but a brief explanation - for example, “we have identified an issue with a database configuration change deployed earlier today” - gives users confidence that the problem is understood and a fix is in progress.
Monitoring: After applying a fix, move the incident to Monitoring and describe what was done to resolve it. This signals that the immediate problem has been addressed but your team is watching to confirm everything is stable. This is an important stage to communicate because it sets the expectation that while things look better, the incident is not yet formally closed.
Resolved: When you are confident the issue is fully resolved and normal service has been restored, mark the incident as Resolved. Include a brief summary of what happened and what was done to fix it. A clear resolution update closes the loop for users who were following the incident.
Affected Components
When creating or updating an incident, you can select which components on your status page are affected. This links the incident to specific services and helps users understand the scope - for example, “the API is down but the website is unaffected”.
Selecting affected components also updates the visual status indicators for those components on your status page. Users viewing the page can immediately see which parts of your service are impacted without reading through the full incident text. When the incident is resolved, component statuses return to their normal state.
How Incidents Appear to Visitors
From a visitor’s perspective, your status page will show active incidents prominently near the top of the page. Each incident displays:
- The incident title and severity level
- The current status (Investigating, Identified, Monitoring, or Resolved)
- The list of affected components
- A chronological timeline of all updates posted since the incident was opened
Visitors do not need to refresh the page to see new updates - the timeline grows as your team posts additional status entries. Resolved incidents are archived and accessible in the incident history section of the status page, so users can review past disruptions if needed.
If subscribers are enabled on your status page, visitors can opt in to receive email notifications for all future incidents without needing to monitor the page manually.
Auto-Creation from Monitors
Automatic incident creation triggered by monitor state changes is planned for a future release. When available, this will open an incident automatically when a monitor goes down, removing the need for manual intervention during an active outage.
Related Documentation
- Status Page Overview - How automated status pages work
- Components & Monitors - Link incidents to specific components
- Subscribers - Notify subscribers when incidents are created or updated
- Notification Rules - Configure when alerts fire for your team