In 2018 an event hit Azure's South Central US region, and we got the least comfortable part of an outage: telling the customer our service was down. It wasn't a distant third party's problem. To the customer, the outage was ours — and so was the conversation.
What breaks first is communication
When an entire cloud region fails, the technical team goes into recovery mode, and communication gets deferred to "once we know more." It's the most natural mistake and the most expensive one: the customer doesn't need to know everything, they need to know in time what's happening, what's affected, and when they'll hear from you again.
Pro Tip: decide before the incident who speaks to the customer and how often. If you decide it during the outage, the first notice arrives late and the second arrives contradictory.
An architecture came out of the outage
That lesson didn't stay in a closing note. The event led to a geo-redundancy scheme that is still in place today. Since then, whenever there have been partial or broad failures in Azure data centres, the scheme has been part of how we respond — and the lesson is confirmed every time: timely, clear communication is what matters.
Pro Tip: turn every serious outage into an architecture change, not just a document. An RCA that doesn't end in a new control is a well-written apology.
The RCA: objective and honest
After recovery comes the hardest part: an objective, honest RCA. Not one that assigns blame, and not one that protects the brand image — one that says what failed, which control was missing or didn't work, and what changes from now on. That honesty is what strengthens your controls and, along the way, the customer's trust.
Pro Tip: write the RCA for the customer who will read it closely. If the analysis survives that reading, it will also serve you to close the control that was missing.
What's left of this story
Cloud providers will keep having events, and when they do, your customer won't distinguish whose failure it was: they'll judge how long you took to tell them, how clear you were, and what you changed afterwards. Geo-redundancy protects us from the next outage; timely communication and an honest RCA protect the relationship.
Related article: the Google Cloud London outage and why resilience is now regulatoryIn this topic
View the full topicQuick answerDetail
What should a service provider do during its cloud provider's outage?
What breaks first is communication: the team goes into recovery mode and the customer notice gets deferred. The right move is to have decided before the incident who speaks to the customer and how often, because the customer doesn't need to know everything — they need to know in time what's happening, what's affected, and when they'll hear from you again. Then come two equally important pieces: turning the outage into an architecture change (in our case, a geo-redundancy scheme still running today) and writing an objective, honest RCA that survives a demanding customer's reading.
Written and reviewed by Rogelio Barajas González — certified Lead Auditor ISO 27001:2022 and ISO 9001:2015, with direct experience in SOC 1 Type 2 and SOC 2 Type 2. Founder of Barajas Advisory.
Company names, people, and some minor identifying details have been generalized to protect the confidentiality of the organizations involved. The facts, figures, and lessons narrated remain faithful to what happened.
Verify his credentials on LinkedIn:linkedin.com/in/rogelio-barajas-gonzalezLast updated: September 2026
This is one of nine real cases
Cicatrices de Nube — do you want the rest of the stories?
All nine documented cases —FinOps, Release Management, Service Delivery, Compliance, and AI governance— with a self-assessment checklist per chapter and an overall scorecard.
Download the free playbook