Release operations

War-game a hotfix criteria before urgency becomes the path

War-game a hotfix criteria by testing whether the exception rules, blast radius, and rollback proof still protect customers when a deadline is close and the change looks small.

Hotfix policies fail when "customer critical" is undefined, when exceptions dual-count the same change as urgent and as low risk, and when rollback drills live only as a promise. The review needs one written definition of an allowed hotfix, one owner who can deny it, and a documented consequence when the hotfix fails.

Freeze the criteria proposal

Write the severity classes, required evidence, approvers, notification list, and rollback drill requirements. Attach the last five hotfixes with their outcomes and any customer-visible impact. Identify exclusions in plain language. If a class of change is omitted from the criteria, show how that omission affects risk rather than leaving it as a footnote.

Name the approval choice and the conditions that force a hold. Include the ticket fields that compute eligibility so two reviewers can reproduce the same allow or deny label from the same packet.

Seat the hotfix from both sides

Feature owner
Defends why the change cannot wait for the next train and what customer harm the delay would cause.
Release manager
Challenges scope creep, gate reuse, and whether the hotfix reuses an untested path.
DevOps lead
Tests artifact identity, promotion path, and whether the hotfix bypasses required checks.
SRE manager
Checks whether monitors and on-call coverage match the claimed blast radius.
Skeptic
Finds the strongest urgency claim with the weakest rollback evidence.

Run pressure cases on the criteria form

Use Pingpong to walk through a near-miss "tiny config" change, a partner deadline, a security patch that arrives mid-freeze, and a request to waive the rollback drill because staging already looked green. For each case, start from the documented criteria language. Ask who can expand the window and which evidence is required to reverse a deny. Any step that depends on an unnamed person becomes a release condition.

Ask the room to replay one historical hotfix under the proposed rules. If the historical case would have shipped while later causing a known incident, revise the criteria before treating it as standard.

Compare the proposal with the release manager seat and a rollback window stress test. If freeze exceptions are unclear, review a deploy freeze exception. More operating decisions live in the war-game decisions hub.

Publish the hotfix path only after a dry run can reproduce the same allow or deny label from the stored ticket fields without manual reinterpretation.