Google's incident guide puts command outside the reporting chain

A command structure that ignores the org chart only works if it is agreed before anything breaks. Google's guide says it directly: "Incident roles do not follow reporting chains and instead are based on knowledge and incident context" ^[6]. The incident commander coordinates the response, the communications lead issues stakeholder updates and takes inbound questions, and the operations lead stays on mitigation ^[5][3]. Any of the three may delegate tasks to other responders ^[5].

The lineage is explicit. IMAG is based on the Incident Command System, the US standard for responding to emergencies such as wildfires and earthquakes, and it keeps that system's three Cs: coordinate, communicate, control ^[3][4].

The alerting section is where the guide gets specific about what an on-caller is allowed to be woken for. It lists four attributes of a good alerting mechanism: timeliness, coverage of all key user-facing functionality, symptoms over causes, and actionability ^[7]. Alerting on service level objectives, the guide says, gets you the first three ^[8]. That leaves one of the four as a separate editorial judgement about each page ^[2]. On the third, the guide says alerts should be "based on end-to-end measures of customer/client experience, not based on a system's internal behavior" ^[17]. It carves out one exception: preventive alerts on internal metrics such as an approaching hard resource quota, where a system can go from 0% failure to 100% failure instantaneously ^[9]. Otherwise internal-behaviour alerts are discouraged because they do not map to user impact and are fragile, being bound to the implementation as it stood when the alert was written ^[10].

Preparation has to happen whether or not an outage does. Playbooks have to be current, and the guide notes that on-callers must actually know the playbooks and training material for them to help ^[11]. Google's named practice for that is the "Wheel of Misfortune" exercise, which also gives less experienced on-callers somewhere safe to learn ^[12]. Where response steps can be automated, the guide wants them automated, including severity and scope analysis, root cause analysis, and suggested mitigating actions, so on-callers spend their attention on problem solving ^[13].

The guide is process description without measured results: it does not publish detection or mitigation times ^[16]. Written by Google's own reliability engineers, it is not evidence about anyone else's outages. What it does supply is a set of commitments a management team can accept or refuse in calm weather, and refusing them is the default. The guide's demands fall on preparation, and the guide's own framing is that outages are inevitable in any sufficiently complex system ^[14].

Copying three role names takes an afternoon, but playbook currency and drill cadence have a calendar attached and decay ^[11][12]. And the guide's test for a good response asks that users, stakeholders and leaders be told what is affected, how bad it is, what workarounds exist, and when the incident may be mitigated and resolved ^[15].