Google Cloud has published guidance on how customers should respond to platform outages, setting out a six-step workflow for reliability incidents.
The framework - prepare, verify, investigate, report, resolve and review - is designed to help users distinguish between faults caused by Google, their own systems or third-party services.
Customers are urged to start well before any disruption by designing systems that can tolerate failure, keeping observability data in redundant locations, maintaining clear response playbooks and running regular training drills.
On system design, Google Cloud recommends automating as many recovery actions as possible. Examples include load balancers redirecting traffic away from slow or unresponsive instances and reviewing applications in advance to reduce manual intervention during an incident.
The guidance also places heavy emphasis on logging, tracing and monitoring data. Teams should ensure timestamps are synchronised across observability tools so engineers can correlate events quickly when a service begins to fail.
Verification step
Once a disruption is suspected, customers should first verify what has failed and who is most likely responsible for fixing it. That means determining whether the source is a Google bug or hardware issue, a customer configuration change or quota limit, or a third-party dependency.
Google Cloud points customers to its own health reporting tools as the first source of information. Personalized Service Health should be checked before the public Cloud Service Health dashboard because it can show incidents limited to specific projects or regions that may not appear on the public site.
Google Cloud distinguishes between "Emerging Incidents", where engineers are still investigating the impact, and "Confirmed Incidents", where customer effects have been verified. The public dashboard is intended for broad, severe incidents affecting large numbers of users, while smaller disruptions may not appear there.
For organisations running workloads across more than one cloud provider, an early cross-check can help isolate the source of the problem. If similar symptoms appear across multiple providers, the issue is more likely to sit outside the cloud platforms themselves.
Investigation and reporting
If Google has not declared an incident, internal investigation should focus on error rates, latency changes, traffic drops, quota ceilings and recent configuration changes. Teams should also examine maintenance and rollout history, as some problems only become visible after a delay.
Where no clear external cause is found and symptoms appear immediately after a change, Google Cloud recommends reverting to the last known good configuration. This reflects a standard incident-management approach in which rollback remains one of the fastest ways to restore service.
The guidance also explains how customers should report issues that do not appear on either health dashboard. It advises filing a support case with a clear statement of business impact, affected project and region, relevant timestamps and sample errors or log snippets.
Priority levels are split between P1, for critical production failures with no workaround, and P2, for significant degradation where an alternative path may still exist. Customers on higher-tier support plans are told to use the escalation option within a case if a critical issue is not receiving sufficient attention.
Mitigation advice
During an active outage, customers are told to keep stakeholders informed and consider failing over to healthy regions or zones if their architecture supports it. However, teams should first confirm that the issue sits at infrastructure level rather than inside their own workload before moving traffic elsewhere.
Temporary workarounds may also appear in health updates while engineers work on a permanent fix. For some issues, especially control-plane problems or highly localised product faults, waiting for a provider-side remedy may be the only realistic option.
The document includes a breakdown of common outage patterns and suggested responses. A software problem tied to a rollout may hit one zone or region and only a subset of products, while a power or cooling problem may affect most services in a single zone. Backbone network faults are more likely to affect a whole region, while capacity shortages or quota exhaustion are situations in which no formal incident may be declared at all.
That distinction matters for customer planning. In stockout or quota cases, users may see error messages but no service-health alert, placing more weight on internal monitoring, demand forecasting and reserved capacity planning.
Post-incident review
After systems stabilise, organisations should conduct a blameless post-mortem to identify what worked, what failed and where luck influenced the outcome. Teams should then update playbooks, tools and training so the same weaknesses do not recur during the next incident.
Major Google-caused outages may result in post-mortems or incident reports being made available through service-health channels. Premium support customers that opened a P1 case can also request an incident summary tailored to their own environment, including the start and end times of the impact.
The guidance underlines a wider shift in cloud operations towards formal incident discipline as businesses spread critical systems across multiple regions, products and external dependencies. It also shows that, despite increasingly sophisticated tooling, outage response still depends on basic operational preparation: clear roles, reliable telemetry, rehearsed processes and the ability to decide quickly whether to fail over, roll back or wait for the provider to restore service.
Google Cloud notes that highly localised incidents may not appear in either public or personalised health reporting, making customer-side preparation and investigation essential when services fail without an obvious platform-wide alert.