# Best practices for handling cloud reliability incidents > Source: > Published: 2026-09-15 16:00:00+00:00 Cloud outages can range from global service disruptions to issues isolated to a specific region, zone, or even just your project, workload or application. If you suspect a Google Cloud Platform outage is impacting your services, we recommend you follow a structured “Verify→ Investigate→Report→Resolve→Review" workflow to resolve it. And before that outage occurs, you should also have prepared your environment for an eventual disruption by designing for failure, and actively practicing the steps you need to take to restore service. In this blog, we summarize the key reliability incident handling best practices to help you design and practice your reliability incident response capabilities and minimize impact. Rather than an exhaustive guide, this is meant as a primer on only the most important practices for advisory purposes. Please note that we do not cover additional practices specific to security incidents here. Beyond the base steps covered here, you may want to also explore how AI agents and tools are starting to transform incident handling. Check out [this episode of the Prodcast](https://sre.google/prodcast/transcripts/sre-prodcast-04-09/), where Googlers explore the latest trends of [leveraging agentic AI in Site Reliability Engineering](https://sre.google/prodcast/transcripts/sre-prodcast-04-09/) (SRE) to detect issues early and prevent disruptions. Try [Cloud Assist investigations](https://docs.cloud.google.com/cloud-assist/investigations), or explore [Agent Skills](https://github.com/google/skills) and [remote managed MCP servers](https://docs.cloud.google.com/mcp/supported-products) to give you another set of tools for quickly pinpointing an issue. Before getting into these advanced techniques, we focus below on the foundational steps to good incident handling. Long before things start to go sideways, you should have spent significant time preparing for an outage along at least four dimensions: design, data, playbooks and training. **Design**: Think ahead and mitigate future incidents by designing automated response actions, like a load balancer shifting traffic away from slow or unresponsive instances, or by automating as much of your incident response playbook as possible. Review [designs](https://docs.cloud.google.com/architecture/framework) of all critical applications to automate as many actions as possible to accelerate response and recovery. **Data**: When a disruption occurs, having meaningful data at your fingertips vastly improves response capabilities. Use [Cloud Logging](https://docs.cloud.google.com/logging/docs/overview), [Cloud Trace](https://docs.cloud.google.com/trace/docs) and [Cloud Monitoring](https://docs.cloud.google.com/monitoring/docs/monitoring-overview), or other third-party observability tools, and replicate that data to a redundant stack in a separate location from the systems being observed. Make sure, in advance of any incident, that time stamps are synced across your observability streams for easy correlation, or know how to do that on-demand during an outage, when time is of the essence. **Playbook**: A well-thought-out playbook documenting your incident response processes, including crystal clear role and responsibility definitions for all personas, is paramount to efficient incident response. Who is responsible to do what? Who needs to be notified or mobilized for each type of disruption? How can they be reached? What tools and data are available? How are results communicated? How do teams hand over to the next shift during long running incidents? etc. Conduct a simulated incident response and critically review every step to find where your playbook needs clarification. Without clear responsibilities, mitigation inevitably takes longer. **Training**: Hopefully, service disruptions are rare events. To ensure your staff knows and remembers how to react, they need to retrain on the process several times per year by running simulated cross-team incident response drills. A retrospective on the simulated exercise will help identify warranted improvements. Despite your best efforts, sooner or later, a service disruption will occur, which you can detect via any number of mechanisms: Observability tools ([Google tools](https://docs.cloud.google.com/docs/observability) or third-party tools) [Unified Maintenance Management](https://docs.cloud.google.com/unified-maintenance/docs/overview?_gl=1*1028q22*_ga*ODU2MjY4NzUyLjE3NzM0MTg2Mjk.*_ga_WH2QY8WWF5*czE3NzM2ODQ4MTckbzQkZzEkdDE3NzM2ODUwMjUkajEyJGwwJGgw) notifications for planned maintenance [Personalized Service Health](https://www.google.com/search?q=https://console.cloud.google.com/service-health) notifications managed with alert policies Proactive customer monitoring by Google Now, you need to determine what broke and who should ultimately fix the problem: Google, e.g., a bug, code roll-out, hardware failure, etc. You, e.g., a configuration change, elevated load, quota ceiling, etc. Third party, e.g., a directory hosted by a different cloud provider If Google has declared an incident and started working to fix the problem, estimate whether you can possibly reestablish service sooner, for example by failing over to a secondary stack (see the ‘Typical Causes’ table below). You can determine whether Google has declared an incident and will provide a fix by consulting: **Personalized Service Health****:** **Check this first.** Personalized Service Health shows incidents specifically relevant to your projects and regions, distinguishing between incident types:.  Emerging Incidents: Google has received an alert, on-callers are investigating, impact is yet unknown Confirmed Incidents: Google has investigated and found customers are impacted Located within the Google Cloud console, Personalized Service Health often displays limited-scope incidents that don't appear on the public dashboard. Personalized Service Health also offers a mobile client for Android and iOS smartphones, assuming you can use your work ID and credentials on the phone. [**Gemini Cloud Assist**](https://g.co/kgs/j2BVWVE), which is [integrated with Personalized Service Health](https://cloud.google.com/blog/products/devops-sre/gemini-cloud-assist-integrated-with-personalized-service-health?e=4875480), so you can use it to query that information in natural language. **Cloud Service Health dashboard****:** This is the public-facing non-authenticated web page for broad, severe incidents affecting many customers. Limited blast radius disruptions are not externalized to the public. All its content is available in Personalized Service Health as well. If ever Personalized Service Health goes down, Cloud Service Health serves as an alternative channel built on a separate infrastructure. **Known Issues:** In the console, navigate to **Support > Cases**, view a case, and use the resource selector on the console toolbar to find the specific cloud resource you’re interested in. Then click **Known issues**. If your issue matches one listed here, you can link a support case to it, so you will receive automatic updates in your case record. If you don’t find a match, open a new support case. Google will automatically match the case to a related incident, as soon as one is declared. Google declared incidents are updated as new information becomes available, so check back regularly, or set up a Personalized Service Health alert policy to be notified each time new information becomes available. If you host cloud resources in multiple clouds, a good practice is to check early on whether the problem occurs for multiple cloud providers. If so, the problem is likely external to the providers and caused either by you or by a third-party service that your application interacts with. To determine the blast radius within your cloud footprint of Google-declared reliability incidents, first check Personalized Service Health updates for a description of the technical problem. Knowing what to look for will allow you to map your blast radius and decide on suitable contingency actions quicker. If Google hasn’t declared an incident, try to rule out configuration errors or issues within your environment by checking: **Cloud Monitoring:** Look for spikes in error rates (e.g. 5xx errors), increased latency, or drops in traffic in your dashboards. **Cloud Logs:** Use **Log Explorer** to look for specific error messages like DEADLINE_EXCEEDED, SERVICE_UNAVAILABLE, or specific API errors. **Quotas:** Ensure you haven't hit a project quota (e.g., CPU, API rate limits), which can often mimic the behavior of an outage. **Change history:** Check your log of recently applied changes. Not all problems manifest immediately, but proximity on a timeline can be a powerful indicator of causality, even if it’s not proof. Also check whether Google rolled out any updates just before the symptoms started. See the [Unified Maintenance Management](https://docs.cloud.google.com/unified-maintenance/docs/overview?_gl=1*1028q22*_ga*ODU2MjY4NzUyLjE3NzM0MTg2Mjk.*_ga_WH2QY8WWF5*czE3NzM2ODQ4MTckbzQkZzEkdDE3NzM2ODUwMjUkajEyJGwwJGgw) interface in Cloud Hub. Absent a clear culprit, such as a traffic spike or a DDOS attack, and if symptoms manifested immediately after rolling out a change, a good strategy is to back out that change and attempt to return to a last known good configuration. If the Cloud Service Health and Personalized Service Health dashboards are green but your metrics show a failure, you must report it to Google. **Determine priority:** **P1 (Critical):** Your production service is unusable or severely impacted with no workaround. **P2 (High):** Significant impact or degradation, but a workaround may exist. See [guidance on setting priority](https://docs.cloud.google.com/support/docs/best-practices#setting_the_priority_and_escalating) and [guidance on describing your issue](https://docs.cloud.google.com/support/docs/best-practices#describing_your_issue). **File a case:** Go to **Support > Cases > Create Case** in the console. **Explain** quantifiable business impact to rationalize the submitted priority and prevent it from being reset when Cloud Support prioritizes cases. A clear and accurate rationale helps! **Essential information to include:** **Project ID** and affected **region/zone** **Timestamps** (when it started and if it's ongoing) with a clearly labeled timezone **Specific error messages** or log snippets **Scope:** Is it affecting all users/systems, or a specific subset/location? If you have a **Premium** or **Enhanced** support plan and a P1 case is not receiving the attention it requires, use the [**Escalate**](https://docs.cloud.google.com/support/docs/best-practices#escalating) button within the support case in the console. This alerts a support manager to investigate and rectify the situation. By taking these steps, you are well on your way to resolving the outage. In the meantime, here are some ways to mitigate the impact of the outage and communicate with impacted stakeholders. While waiting for a resolution: **Communicate:** Notify your stakeholders and customers. Transparency helps manage expectations and reduces duplicate internal reports. **Fail over:** If you have a multi-regional architecture, consider shifting traffic to a healthy region. As a best practice, first ensure that the disruption is at the infrastructure level and not at your workload level.  **Check for workarounds:** While working on a permanent fix, Google often posts temporary workarounds in the Service Health Dashboard updates, or in Personalized Service Health updates. **Consider your regulatory reporting requirements**: Know whether your organization is subject to regulatory reporting requirements, and what the required deadlines are for both initial and follow-up reporting. Google Cloud prepares Incident Reports for incidents that meet certain criteria — see details [here](https://docs.cloud.google.com/service-health/docs/get-incident-reports) for how to get those reports. Premium Support customers can also request an Incident Summary, which is an Incident Report customized to your account’s specific hosting location, time stamps, etc. Once systems are stable, Google downgrades the severity levels and deactivates the active on-call escalation chain. Google only closes an incident in Personalized Service Health when it has taken all the mitigation steps covering all impacted customers. Your specific services might be restored sooner than the incident closure time, if other customers are restored later than you. The incident is officially closed on the Google Cloud Status Dashboard when systems have run stably for a designated auto-close duration. Verify that your services are operating normally at this point. And if your incident responders aren’t compensated for extra time spent on the incident, find a way to thank them. After the problem has been fixed and operations have returned to a normal, steady state, it’s time to conduct a [post-mortem analysis](https://docs.cloud.google.com/architecture/framework/reliability/conduct-postmortems) to identify how your team can respond better in future service disruptions. A “blameless” approach is essential to surfacing meaningful and impactful improvements that can be made to your incident response process. Ask questions like: What went well? What could we have done better? Where did we get lucky? Where did we get unlucky? Then decide what changes can be made to improve your playbook, tools and training. At Google, we often publish a **post-mortem** or **Incident Report** for major outages, available via Personalized Service Health. Review this to understand the root cause and adjust your own disaster recovery plans to prevent or reduce future impact. Customers with a Premium Support plan can request an **Incident Summary** for a Google-caused incident they were impacted by and for which they opened a P1 case. An Incident Summary is an Incident Report customized for your environment (e.g., start and end times of impact). To help you prepare and plan ahead, here’s an overview of some typical incidents based on the symptoms reported in Cloud Service Health and Personalized Service Health along with guidance on what Google communications to expect, and some generic mitigation or prevention strategies you can build into your playbooks. | **Blast radius** | **Typical cause** | **Comms** | **Strategy** | | Single zone or region.Subset of products. | Typical of a software problem triggered by a rollout. Learning points: - Understand the location scope (zones and regions) of your workload - Products can depend on other products | Major incidents are communicated via Cloud Service Health.Major and Minor (by number of customers, not severity) incidents are communicated via Personalized Service Health. Highly localized incidents are not communicated via Cloud Service Health or Personalized Service Health. | Fail over, if so configured, but verify the health of the secondary stack first. | | Single zone.Most or all products. | Typical of a power or cooling issue. | Check Cloud Service Health and Personalized Service Health. | Fail over to a different zone, if so configured. | | Single region. Most or all products. | Typical of a backbone networking infrastructure issue | Check Cloud Service Health and Personalized Service Health. | Fail over to a different region, if so configured. | | Control plane issue for a product | Typical of a late detected issue | Communicated via Personalized Service Health if significant customer impact is verified. | Look for workarounds. Wait for Google to fix. Fail over, if so configured. | | Multi-regional issue with a global product | Rare but possible, typically detected quickly. Learnings: Mitigation options can be limited. Try regional variants, alternative products with similar functionality | Check Cloud Service Health and Personalized Service Health. | Wait for Google to fix. In the meantime, verify via Google Comms and your own investigation that this is truly Google’s problem to fix. | | Capacity / Stockout issue | System-level demand exceeding capacity in the product/location/model. (Cloud is designed to scale, but limits always exist, so proper planning is advised) | Error message. No incident will be declared. | Place reservations for predicted capacity needs (if cost is acceptable). Flexibility in zone placement can also help. | | Quota exhaustion | Difficult / inaccurate prediction of traffic | Error message. No incident will be declared. | Review consumption trends against ceiling regularly. | This document offers only a condensed summary of key points. If you have an active Premium Support contract with Google Cloud, reach out to your account team for a deeper review of your response plans. For a comprehensive treatise on how to build reliable services and how to respond to incidents, we strongly recommend Google’s [SRE Book](https://sre.google/sre-book/table-of-contents/), which is available as a free download. A new version of the SRE book is releasing ~Oct 2026 and will be available for purchase on O’Reilly Media. We’re also working on a future primer that explores AI-supported incident handling in-depth — stay tuned!