opsphieBeta

Guide

Incident response

A good response is a practiced habit: clear roles, one channel, and a known path from “something's wrong” to “we learned from it.”

Declare early

/inc new opens a channel, pins a control panel and starts the timeline. Pick a severity, P0 (worst) to P3, and change it as you learn more.

Not an incident after all? /inc cancel: the timeline stays, and reports leave it out.

Name a commander

One person runs the response and makes the calls. Add a manager to keep stakeholders informed, and a postmortem runner for afterwards.

Move it along

Change status with /inc status as the response moves on.

  1. 1Investigating

    Something's wrong, and you don't know why yet.

    Gather signal, and post /inc update as you learn. Move on when you can say what broke.

  2. 2Identified

    You know the cause.

    Stop the impact first, with a rollback, a failover or a feature flag. The real fix can wait.

  3. 3Mitigated

    Impact has stopped, though the fix may only be temporary.

    Move here the moment customers stop feeling it: that's your time to mitigate. Then get back to normal.

  4. 4Resolved

    Service is back to normal, and responders can stand down.

    /inc resolve and say how. The permanent fix doesn't have to have shipped: that's a remediation.

Learn from it

/inc postmortem starts one from your template, filled with the incident's own timeline and times. Write it blameless, about conditions, not people. Review it, then publish.

Track follow-ups with /inc remediation. With Jira connected, each one becomes a Jira issue.

Every step is timed

Status changes record when the cause was identified, and when the incident was mitigated and resolved. Reports show time to detect, mitigate and resolve, and time spent in each status.