Incidents overview

Incidents give your team a shared place to coordinate urgent or customer-impacting production work. They collect the current status, owner, severity, related errors, timeline, and context needed to understand what happened and what happens next.

What is an incident?

An incident represents active operational work around a failure, outage, degraded service, or risky production condition. It is broader than a single error group: one incident can include multiple errors, logs, uptime failures, performance changes, deploys, and team actions.

Use the incident as the coordination record while the work is active. The incident should answer who owns the response, what the current impact is, what changed recently, and what the team has decided so far.

When to create an incident

Create an incident when an issue needs coordinated response rather than routine error triage. If one person can quietly fix a low-impact error, an assigned error group may be enough. If multiple people need shared context, create an incident.

• A production error affects customers or a critical workflow.
• An uptime monitor reports an outage or degraded service.
• A release appears to introduce a high-impact regression.
• Multiple signals point to the same operational problem.
• The team needs a timeline, owner, status, and follow-up record.

Incident severity

Severity communicates urgency and expected response. Use the smallest severity that honestly reflects customer impact, and adjust it as new information arrives.

• Critical for broad outages, data loss risk, or blocked core workflows.
• High for significant customer impact with a workaround or limited scope.
• Medium for meaningful issues that need timely follow-up.
• Low for minor impact, investigation, or tracking.

Coordinate the work

Keep the incident current while the response is active. A useful incident page should make the next action obvious to anyone joining the work.

• Assign an owner for coordination.
• Record the current status and known impact.
• Link related error groups or project signals.
• Add notes when the team makes a decision or learns something important.
• Keep external issue links or communication links attached when relevant.

Connect signals

Incidents are most useful when they gather the signals that explain the problem. Review related errors, logs, uptime checks, performance changes, infrastructure signals, and recent releases before deciding on a fix or mitigation.

When several signals point to the same failure, use the incident to keep them together so teammates do not have to rediscover context across separate screens.

Common investigation paths include logs for nearby application behavior, performance for latency or query regressions, infrastructure for saturation, uptime for external availability, and session replay for user-path evidence.

Resolve an incident

Resolve the incident when the customer-impacting condition is fixed or the team agrees no further active response is needed. Before resolving, confirm the main signal has recovered and that any related error groups are muted, resolved, assigned, or tracked elsewhere.

• Confirm the service or workflow has recovered.
• Record the final status and the mitigation or fix.
• Link follow-up work that remains after the active response ends.
• Update related error groups so future triage reflects reality.

After the incident

After resolution, use the incident record to understand what changed and what should improve next. The best follow-up items are concrete: better alert routing, clearer ownership, stronger tests, safer deploy checks, or improved customer communication.