How to Triage a Production Bug in 15 Minutes: A 5-Step Playbook

The single most useful framing: triage is the meeting where you decide what to do, not the meeting where you do it. A clear triage outcome lets the actual fix work happen in parallel with stakeholder communication and root-cause investigation, instead of all three competing for the same attention.

If you're not sure whether the clock has started, ask: "do I have a specific user-facing symptom and a way to reach the on-call engineer right now?" If yes, the clock is running. If not, you're still in detection, not triage.

The Slack message template:

Drop the link, ping the names, hit send. Don't wait for confirmation before moving to step 2.

The repro checklist for the 5-minute window:

1. Open the affected URL in an incognito window with the same user state if possible.
2. Check the customer's session replay if you have one — this is where session-replay tools (rrweb, BugMojo, etc.) pay off.
3. Check the error tracker for the exception fingerprint and affected user count.
4. Check deployment timestamps — was there a recent deploy that correlates?
5. Check the database — is there a data anomaly?

Two failure modes to watch for:

• Severity inflation under pressure. Customers calling it CRITICAL doesn't make it CRITICAL; it makes it loud. Hold the bar.
• Severity deflation to avoid escalation. "It's only HIGH because the workaround is annoying" — if every user has to do the workaround on every interaction, it's CRITICAL.

For the deep definition of the severity levels and the priority dimension, see our bug severity vs priority decision framework.

Public status update template:

Internal Slack template:

Leadership ping (CEO/CTO if CRITICAL):

The handoff template:

• Treating triage as the fix. The clock runs out, the bug is still unfixed, and you've burned the urgency capital. Triage ends with a plan, not a code change.
• Pulling in too many people. Three is the sweet spot. Five becomes a town hall; ten becomes paralysis.
• No timestamps in updates. "Next update soon" is useless. "Next update by 11:45 AM PT" is actionable.
• Skipping the post-triage handoff. The on-call moves on, the fix owner forgets the context, and the bug stalls.
• Speculating publicly. Status pages are not where you brainstorm. Write what you know.

Time 11:00 AM. PagerDuty fires: error rate on POST /checkout spiking from 0.2% to 8%. On-call engineer Alice acknowledges within 90 seconds, opens #incident-2026-05-22-checkout, pings @bob (last touched /checkout controller) and @carla (CSM lead).

11:02 — repro attempt. Alice tries to check out herself: succeeds. Checks the session-replay tool — sees 3 affected sessions in the past 10 minutes, all from users on a specific payment method (prepaid cards). Repro pattern: known.

11:07 — severity assigned. "Affected users get a 500 with no recovery path. Not all users, but the affected ones lose the cart. HIGH severity, not CRITICAL — workaround is to use a different card."

11:11 — next action. Recent deploy at 10:45 AM added a new validation step that mishandles prepaid card numbers. Rollback is safe (no DB migration). Decision: rollback.

11:13 — communication. Public status: "Some users on prepaid cards are seeing checkout errors. Workaround: use a different payment method. Rolling back the affected change now, ETA 5 min." Internal Slack: SEV2, Alice owning rollback, ETA 11:20.

11:20 — rollback complete. Triage closed in 20 min (5 over budget — acceptable for a SEV2).

• Build a runbook with the 5 templates above hardcoded into your incident-channel auto-create flow.
• Practice the playbook quarterly with a game day — invent a fake SEV1 and run through the 15 minutes.
• Capture session replays in production so step 2 doesn't depend on your ability to reproduce locally. BugMojo auto-captures rrweb session replay + console + network for every error, so the on-call has the evidence in hand before they open Slack.

For more on severity assignment specifically, read our bug severity vs priority decision framework.