Who can authorize the next incident mitigation?

In a hypothetical incident, the room agrees rollback may help, but nobody has established whether the older code can read the migrated data. The commander can organize that investigation without owning every permission needed to act. Service and data owners still authorize the consequential change.

Two delays can look identical in chat. One team is still investigating compatibility; another understands the risk but cannot reach its approver. More telemetry may help the first. The second needs a person and a usable contact route.

Break “can we roll back?” into those real questions: will the old code understand today’s data, who can accept the remaining risk, who applies the change and who checks the result? Coordinating those answers is the commander’s job.

Coordination and authorization have different jobs

Call the commander in this hypothetical incident Mira. A responder asks her to approve rollback. Mira can get the proposal into a form the service and data owners can decide on, but her coordinating role does not grant their permissions. The team needs to know who can approve the scope, who will execute it and who will accept the resulting evidence. In a small incident one person may hold several of those jobs; naming the decisions still prevents “commander” from becoming permission by implication.

Google's incident-response guidance supplies a foundation for coordination. For Mira, the practical test is whether the assigned roles can reach someone authorized to accept the rollback’s data-affecting consequence. A name on the role chart is useful only if the route reaches that person or an authorized fallback.

This is easier to prepare before the incident. A schema rollback, cross-region traffic move or destructive recovery may belong to a different owner from an ordinary deployment. Allowed scope, a reachable fallback and a condition that stops the action give Mira a route to use rather than a new search to begin while the service is failing.

The compatibility question inside a rollback debate

The failure followed the deployment, which explains why rollback entered the conversation. It does not tell Mira whether the older code can read the migrated data. The proposal is now waiting on a narrower technical question: compatibility between that target version and the affected data, not whether rollback is generally a useful incident response.

Mira assigns the compatibility check to someone able to verify that target version against the affected data, with a review point suited to the service risk. Another owner assesses bounded traffic reduction in parallel. The owners can investigate both possibilities without independently turning their proposals into conflicting production changes.

Suppose the review point arrives and compatibility is still unknown. “Rollback is ready” would erase the very question holding it up. Mira instead brings the open compatibility check and the traffic-reduction assessment to the established authorization path. The authorized owner can consider the remaining options with the uncertainty intact; Mira keeps the evidence and next review moving.

The evidence available when a decision was made

A responder joining now finds a short decision note: immediate rollback is deferred because compatibility remains unresolved. It names the proposed target and scope, the expected change, the person checking the result and what new observation would reopen the choice. That is enough to explain why the team has not simply pressed rollback.

At the shift boundary, Mira uses that note in a live handoff. Google’s incident-management guidance calls for briefing the incoming commander, obtaining explicit acceptance and telling the other responders who now leads. The incoming commander hears which compatibility question is still open, who is handling it and when it will be reviewed next, then explicitly accepts coordination. The service and data-risk authorization path has not changed with the shift.

If an action is later approved and applied, the next update still needs to say what the service did. A successful command may mean only that an interface accepted the operation while customers remain impaired. For asynchronous work, new requests might recover while old jobs remain in the backlog. The incoming commander needs both observations to know when coordination can reduce and which recovery work still has an owner.

The note can grow as those events happen: proposal, approval of a specific target and scope, execution, then verified service behavior. It must not fill in later events merely because an earlier one occurred. The incident decision-log replay kit lets another responder reconstruct those distinctions from a synthetic record, including the branch where the execution result is missing.

Service recovery and backlog recovery can diverge

Read diagram description

For asynchronous work, new requests may succeed while older jobs remain delayed. Report both states and check replay for duplicate side effects before claiming that all affected work has completed. Diagram labels: Mitigation applied: Begin independent recovery checks; New work: Is the live user path healthy?; Earlier work: Which jobs remain delayed or failed?; Recovery handoff: State both results, replay needs and residual owners.

Response intervals reveal preparation gaps

Afterward, suppose the timeline shows a twenty-minute interval in the response. Was Mira waiting for the compatibility check, looking for the approver, obtaining access or waiting for recovery checks? Each would suggest a different repair. If the time can only be estimated, it remains an estimate in the record rather than acquiring false precision because someone typed it into a table.

If the technical answer was already available but the approver was not, delegated scope or better coverage may shorten the next wait. If two owners made conflicting changes, their action ownership needs attention. If the team could act but could not tell whether requests recovered, the verification needs work. The useful improvement is whichever interval actually changes, not a smaller total detached from what the responders were doing.

For a small, familiar incident, a single concise entry may be enough. Expand the structure only when uncertainty, scope, or concurrent work warrants it. Maintaining the record should support the recovery decision rather than become more urgent than it.

Carry the record into the post-incident review to examine the options and constraints that shaped the response. Retain uncertainty where it existed; hindsight should help identify a better preparation, not rewrite the earlier decision as obvious.

A worksheet for the disputed rollback

The rollback case is ready for rehearsal when the worksheet identifies the compatibility evidence, reachable authorization path and service checks that establish recovery. Each empty field points to a specific preparation problem: an unknown precondition, unavailable authority or undefined result.

The incoming commander can now go straight to the person checking compatibility, rather than ask the room to argue for rollback again. They know where an authorized decision will come from and which service and backlog checks will still be needed afterward. The older code has not become safer because the shift changed. The unanswered question has simply reached someone who can keep it moving.