Creating and Managing Incidents
Learn how to create, update, and resolve incidents to communicate service issues to your users
Incidents are events that affect the availability or performance of your services. They allow you to communicate issues to users and track the resolution process with detailed updates.
Incident Properties
Each incident has the following properties:
Title - Clear description of the issue (e.g., "API latency affecting mobile app")
Status Type - Severity level (degraded_performance, partial_outage, major_outage, incident)
State - Current stage (active or resolved)
Impact - Affected services (minor, major, critical)
Affected Services - List of services impacted by this incident
Description - Initial description of the incident
Created At - When the incident was first reported
Resolved At - When the incident was marked as resolved (if applicable)
Creating an Incident
When an issue occurs, create an incident to communicate with users:
Identify the Issue - Determine what services are affected and the severity
Create the Incident - Add to your status page with a clear title
Set the Status Type - Choose appropriate severity (partial_outage, major_outage, etc.)
Mark Affected Services - Select all services impacted by this incident
Add Initial Description - Provide initial details about what's happening
Publish - Make the incident visible to users on your status page
Incident Lifecycle
An incident goes through several states:
1. Investigating
The initial state when an incident is first created. The team is gathering information and assessing the impact.
2. Identified
The root cause has been identified and a fix is being prepared. This provides users with confidence that the issue is understood.
3. Monitoring
A fix has been deployed and the team is monitoring for resolution. Services should be improving at this stage.
4. Resolved
The incident has been fixed and services have been restored to normal operation. Users can resume using affected services.
Incident Updates
Each incident can have multiple updates that track the resolution progress:
Initial Update - Created automatically when the incident is created
Status Updates - Add updates when the incident state changes
Progress Updates - Communicate progress even when state doesn't change
Resolution Update - Final update when the incident is resolved
Updating an Incident
As you work on resolving an incident, update it regularly:
Change State - Update to "Identified", "Monitoring", or "Resolved"
Add Message - Describe what's new (e.g., "Deploying fix now")
Update Affected Services - Add or remove services as needed
Save Update - Each update creates a timeline entry
Impact Levels
Minor Impact
Affects a small subset of users
Service degradation is minimal
Workarounds may be available
Example: Mobile app shows error for 5% of users
Major Impact
Affects many users
Significant service degradation
Core functionality impaired
Example: API response times are 3x normal
Critical Impact
Affects most or all users
Services are completely unavailable
No workarounds available
Example: Entire API is down
Affected Services
Mark which services are impacted by each incident:
Multi-select - Choose multiple affected services
Dynamic Updates - Update affected services as you learn more
Service Status - Affected services automatically show outage status
Visual Indicators - Users can see which services are impacted
Incident History
Resolved incidents are displayed in the "Past Incidents" section of your status page:
Title and Date - Shows what happened and when
Duration - Displays how long the incident lasted
Impact Badge - Shows severity level
Resolved Badge - Indicates the incident is resolved
Clickable - Users can click to view full incident details
Best Practices
Create incidents promptly when issues are discovered
Update incidents at least every 30 minutes during active resolution
Use clear, non-technical language in incident descriptions
Always mark incidents as resolved when services are fully restored
Conduct post-incident reviews to prevent recurrence
Keep incident titles concise but informative
Include affected services to help users understand scope
Example Incident Timeline
10:00 AM - Incident created: "API latency affecting mobile app" (Investigating)
10:15 AM - Update: "We're investigating increased response times on our API servers"
10:30 AM - State change to "Identified": "Database load caused by recent deployment"
10:45 AM - Update: "Rolling back problematic changes"
11:00 AM - State change to "Monitoring": "Rollback complete. Monitoring API performance"
11:15 AM - State change to "Resolved": "API performance back to normal"
Was this article helpful?