SEV-1 With an Incident Commander Who Is Also the Debugger

• Stop debugging. An IC cannot also be the debugger. Name an ops/technical lead - the stronger of the two engineers already running commands - and hand technical command over. The IC now runs the incident, not the terminal.
• Assign roles by name: ops lead, comms/customer lead, scribe. If nobody is free, the IC keeps comms and drafts a scribe; unnamed roles do not happen.
• Consolidate to one channel and freeze uncoordinated change. Announce that no production changes happen except through the ops lead. Two engineers mutating production on conflicting hypotheses is how a 60% error rate becomes 100%.
• Establish the shape in five minutes: is the provider degraded, and is the blast radius the PoPs or the origin? A 60% drop concentrated in specific PoPs points at the provider; a uniform drop points at origin, config or a deploy.
• Fix the comms that is already wrong. Retract the promised 20-minute ETA on the support side, and move the status page from "investigating" to a concrete impact statement with the time of the next update.
• Start the timeline now, retroactively from 09:12, and have the scribe record decisions rather than chat.

Give three things: current understanding, next update time, and the decision you need from them.

• Understanding: "About 60% of playback starts are failing, concentrated in a subset of CDN PoPs. Provider-side degradation is the leading hypothesis; we are confirming origin health before failing over."
• Cadence instead of an ETA: "Next update at 10:00, then every 15 minutes." Guessing an ETA is how the support team's 20-minute promise happened.
• Ask for the decision only they can make: if failover to the secondary CDN doubles egress cost or needs a contract action, that is their call now, with the tradeoff stated - "failover restores roughly 90% of starts within 10 minutes at 2.5x egress cost; do I have authorization?"

Use the executive for what executives are good for: authorizing spend, approving customer comms and credits, and escalating to the CDN vendor's account team. Keep them in that lane rather than in the debugging channel. If they keep pushing for an ETA, convert it into a plan: "failover decision at 10:00; recovery measurable ten minutes after that." That is a commitment you can keep; a number pulled from the air is not.

• Role separation. SEV-1 requires an IC plus an ops lead. Write it into the runbook and back it with role cards posted in the incident channel.
• IC training and rotation. An IC who debugs is usually an IC who was never trained or who was the only person available. Run monthly tabletop drills and staff a real rotation so a 03:00 SEV-1 has a named commander.
• Pre-authorized actions. CDN failover should be a runbook action with a written trigger - for example, provider 5xx above 5% for 10 minutes across more than 20% of PoPs → fail over - so it does not wait on an executive mid-incident. Test the failover quarterly.
• One comms path. Support cannot promise ETAs. Give them a template and a rule that estimates come from the IC only; automate status page updates from the incident tool if possible.
• Blast-radius control. A written no-uncoordinated-change norm, enforced by an incident change lock, because two conflicting production changes nearly masked the real cause.

Blameless does not mean actionless. Every item needs an owner and a date, and repeating themes belong on the quarterly reliability review, not in a document nobody reopens.