Creating and Managing Incidents

Last updated: 2026-09-14

When something goes wrong with your service, an incident helps you communicate with your users transparently. Here’s how to create and manage incidents effectively.

Tip for Simple Status Pages: If you manage a simple status page (no monitors), you can trigger incidents automatically from the Simple Status Page Dashboard — just set a component status and add a note. No need to open the Incidents page.

When to Create an Incident

Create an incident when:

• Your service is down or unavailable
• Performance is significantly degraded
• A feature isn’t working correctly
• You’re aware of an issue affecting users

Even if only some users are affected, it’s usually better to communicate proactively.

Creating a New Incident

1. Go to Incidents in the left menu
2. Click New Incident
3. Fill in the incident details
4. Click Create

Incident Fields

The incident form no longer shows a separate “connected channels” chooser. Owner/team notification delivery is controlled by your linked status-page channels and notification preferences, not per-incident toggles inside the create/edit form.

Published incidents are permanent history

Review the title, initial message, status page, and notification choice before publishing. Once created, those fields cannot be edited or replaced.

The affected components are the one exception — they can still be added to or removed from the incident afterward. See Editing Affected Components After Publishing.

Communicate every subsequent change by posting a timeline update. Updates can add a message and move the incident forward through its states. They cannot move it backward, and a resolved or archived incident cannot receive another update.

Correcting Effective Incident Time

Title, initial message, and affected component are locked once published — but the Effective Incident Time on the incident’s edit page lets you correct when the incident actually started or ended, separately from when you got around to publishing it in the dashboard:

• Effective start can be edited at any time on a manually-created incident — investigating, monitoring, or already resolved.
• Effective end can only be set once the incident is Resolved — there’s nothing to correct before then.
• End must fall after start; the save is rejected otherwise.
• Auto-created incidents (raised automatically from monitor failures) are scheduler-owned and cannot have their effective time edited manually — the scheduler derives their timing from the actual check evidence.

This matters for uptime/SLA accuracy: if you published an incident a few minutes after the outage actually began, correcting the effective start keeps your historical uptime numbers honest instead of crediting you for downtime that happened before you clicked “Create.”

Incident Statuses

Each incident moves through different states:

Keep your status accurate - users rely on this information.

Adding Incident Updates

As you work on the issue, add updates:

1. Open the incident
2. Scroll to the Add Update section
3. Write what’s happening
4. Change the status if appropriate
5. Click Post Update

Updates appear in chronological order on your status page.

Good Update Examples

• “We’ve identified the issue as a database connection problem.”
• “A fix has been deployed. Monitoring for stability.”
• “Service is fully restored. We’ll continue monitoring.”

Choosing Affected Components

Component selection is optional when creating an incident:

Component-Specific Incidents

Select the component or components that are impacted — you’re not limited to one:

• This updates their status on your status page
• Users can see exactly what’s affected
• Components automatically return to normal when resolved
• If you use runbooks, the best matching runbook can be linked automatically when the incident is created
• If you use per-component subscriber notifications, these incident emails are only delivered to subscribers who selected one of the affected service entries, plus subscribers who stayed on All components

Selecting more than one component reports a single incident that spans all of them — see Incidents Across Multiple Components for how selection order, severity, and monitor targeting work once more than one is checked, and how to add or remove components after publishing.

On the public incident detail page, visitors can inspect the affected-component timeline to see the incident window, its duration, and the exact start and end times in their selected timezone.

Status-Page-Wide Incidents

Leave the component field blank to create a general incident that affects your entire service:

• Use this for datacenter outages, network issues, or service-wide problems
• The incident appears at the top of your status page
• No specific component status is changed
• Subscriber notifications go to all page subscribers, including those who normally follow only a subset of components

See the component management guide if you need help naming or grouping services before linking them to incidents.

Teams and Component-Group Scope

If you manage a shared status page through Teams, your incident access can be narrowed by component group permissions.

• Owners and team Admins can create and manage incidents across the full status page.
• Editors with explicit group assignments only see components and component-linked incidents inside their assigned groups.
• If your editor access is scoped to groups, you cannot create a page-wide incident with no component selected. Choose a component you are allowed to manage, or ask an owner/admin to create the broader incident.
• Ungrouped components are not available to editors who already have explicit group assignments on that status page.

Incident Context Sidebar

After an incident is created, the incident details view includes an Incident Context section.

This can show:

• A linked runbook with response steps
• Impacted monitors for the affected component

Use this sidebar as your responder workspace while the public status message continues to live in the incident timeline.

If you have not set up runbooks yet, start with Using Runbooks for Incident Response.

If you want broader guidance on severity design, update cadence, maintenance copy, and postmortem structure, start with the University incident management hub.

How notification delivery works

When you create an incident or post a timeline update:

• public subscriber delivery follows your subscriber settings and component targeting rules
• owner/team delivery follows the notification channels linked to that status page
• your own signed-in dashboard can additionally use browser notifications or a local incident alarm if you enabled them in Personal Notification Preferences

If you are looking for Slack, Discord, Telegram, webhook, or PagerDuty routing, manage that in Notification Channels Overview, not in the incident form itself.

Writing Good Incident Messages

Example Incident Message

“We’re experiencing issues with our API that may affect integrations. Our team is investigating and we expect to have more information within 30 minutes. We apologize for any inconvenience.”

Resolving an Incident

When the issue is fixed:

1. Open the incident
2. Add a final update explaining the resolution
3. Change status to Resolved
4. Click Post Update

Resolved incidents move to your incident history but remain visible on your status page for the configured number of days.

If you are using Try Demo, note that demo incidents follow a different lifecycle: they are temporary, auto-cleaned, and may be deleted after completion rather than kept as part of long-term incident history. See Using Demo Incidents.

Viewing Incident History

To see past incidents:

1. Go to Incidents in the left menu
2. All incidents are listed with their status
3. Click any incident to view details and updates

If you want to reduce noise on your status page, you can also archive resolved incidents. Archiving hides them from incident lists while keeping the history and direct link accessible.

Demo incidents are different from archived incidents. Archived incidents remain accessible by direct link, while completed demo incidents can be deleted automatically after cleanup. See Using Demo Incidents.

What’s Next?

• Link an incident to multiple components when one root cause affects more than one service
• Use incident templates to save time
• Use runbooks to keep response steps attached to incidents
• Set up on-call rotations to auto-assign new incidents
• Incident Tasks — track response steps during an active incident
• Postmortem Reports — write a post-incident review after resolution
• Automatic Incident Management — auto-create incidents from monitor failures
• Schedule maintenance windows
• Set up subscriber notifications
• Target subscriber delivery by component
• Browse University incident management guides