Skip to main content

Resolving incidents

Updated

Resolving an incident marks it as closed and ended. It records who resolved it, when it was resolved, and captures any final notes. Resolved incidents are preserved with their full timeline and are included in MTTA/MTTR reporting. Resolving is the final step in the incident lifecycle: triggered → acknowledged → resolved.

Technicians resolve incidents once the underlying issue is fixed or the alert condition has cleared.

Resolving an Incident

  1. Open the incident from the dashboard or incident list.
  2. Confirm the issue is actually fixed before resolving. Resolving a re-triggered alert that is still ongoing will just create a new incident when the next alert arrives.
  3. Click Resolve.
  4. Add a brief resolution note explaining what was done and what caused the issue. This note appears on the timeline and is available in post-incident reviews.
  5. The incident moves to the resolved state. Your username and the current timestamp are recorded as resolved_by and resolved_at.

Adding Notes During an Incident

Notes can be added at any point during the incident — not just at resolution. Use notes to document:

  • What you observed when you first looked at the issue
  • Steps taken and their results
  • Changes made to fix the problem
  • Context for handoff if ownership is being transferred

To add a note, open the incident and click Add Note. Notes appear in the incident timeline in chronological order.

Reading the Incident Timeline

The timeline is an ordered log of everything that happened during the incident:

  • When it was triggered and by which source
  • Each escalation step that fired, with timestamps
  • Who acknowledged it and when
  • Notes added by responders
  • War room updates (if a war room was opened)
  • Playbook execution steps
  • When it was resolved and by whom

The timeline is useful for post-incident reviews and for understanding response patterns across incidents.

Creating a Post-Incident Review

For significant incidents, create a Post-Incident Review (PIR) once the incident is resolved:

  1. Open the resolved incident and click Create Post-Incident Review.
  2. Fill in root cause, contributing factors, a timeline of events, and what went well or wrong.
  3. Add action items with owners.
  4. Save as a draft. Share with the team for edits.
  5. Click Publish when complete. Published PIRs are read-only.

Auto-Resolution

OnCall will automatically resolve acknowledged incidents that haven't been touched within the service's auto-resolve hours (default: 4 hours). The incident is resolved with resolved_by: system and a note is added to the timeline. This only applies to incidents in the acknowledged state — triggered incidents are not auto-resolved, they continue escalating.

If you are working a long-running acknowledged incident, add a note or update the incident to reset the auto-resolve clock.

Logging Time at Resolution

After resolving, log the time you spent working the incident:

  1. Open the resolved incident and click Log Time.
  2. Enter start and end time (or duration) and notes. Mark as billable if applicable.
  3. The entry appears in Time Tracking for admin review and PSA sync.

FAQ

Can a resolved incident be re-opened? Not directly re-opened — but if the same alert fires again after resolution, OnCall creates a new incident (because the old one is resolved and the fingerprint deduplication only applies to open incidents). If you need to track ongoing work, keep the incident in the acknowledged state rather than resolving it.

What's the difference between resolved and closed? The resolved state is the standard end state. The closed state exists in the data model as an additional terminal state but the typical lifecycle ends at resolved.

Does resolving an incident stop any pages still in flight? Yes. Once an incident is resolved, the escalation engine ignores it. Any pending pages for open escalation steps will not fire.

Related