How to Communicate With Customers During a Cloud Outage: A Runbook
August 16, 2026
On July 24, 2026, an AWS outage in US-West-2 took DoorDash, Reddit, Hulu, Apple Pay, Snapchat, Fortnite, and the PlayStation Network offline. None of those companies shipped a bad release that morning. Their customers did not care. Yours will not either: when your cloud provider fails, the outage shows up on your status page, your support queue, and your churn report. You cannot fix the provider's fault. You can control the one thing that decides whether customers stay: how fast and how honestly you tell them what is happening.
A good response is boring on purpose: acknowledge fast, update on a fixed rhythm, tell the truth.
The single most important takeaway: publish your first customer-facing update within 15 minutes of confirming impact, then post again every 30 minutes, even when the update only says "still investigating." No update is still an update to a worried customer: it means you forgot about them. Silence loses accounts. The outage alone rarely does.
Why the communication is the job
Provider outages are different from your own incidents: the blast radius is bounded by everyone sharing the region or dependency, not by your code. The May 2026 us-east-1 cooling failure took about 28 hours to restore and left Coinbase offline for roughly seven hours. In October 2025 a DynamoDB DNS failure in the same region ran about 15 hours and, by CyberCube's estimate, touched roughly 70,000 organizations. Recent status histories look like this:
| Date | Provider | What failed | Duration | Notable impact |
|---|---|---|---|---|
| May 7-8, 2026 | AWS | us-east-1, cooling failure in one AZ | ~28 hours | Coinbase, FanDuel, CME Group |
| Oct 20, 2025 | AWS | us-east-1, DynamoDB DNS | ~15 hours | ~70,000 orgs affected (CyberCube est.) |
| Oct 29-30, 2025 | Azure | Front Door, config change | ~8.5 hours | Global edge and CDN customers |
| Jun 12, 2025 | Google Cloud | IAM / Service Control, quota policy | ~3 hours | Dozens of products, multi-region |
| Jan 8-11, 2025 | Azure | East US 2 (AZ01), networking change | ~50 hours | Regional VMs and dependent services |
The teams that looked competent on July 24 were not the cleverest architects. They recognized the pattern in the first minutes and kept talking while the fix sat in someone else's data center. Your users do not have an AWS support contract. They have you. The first job in the first ten minutes is attribution, not fixing: check the provider status page (treat it as lagging, because it often is), an external tracker, and your own dashboards. If several unrelated services degrade at the same second and your last deploy was hours ago, it is upstream. Do not roll back healthy code during a provider incident; you only lengthen the outage.
The communication timeline that keeps trust
Practice is consistent on cadence: first acknowledgment within 10 to 15 minutes of confirming impact, then updates every 30 minutes for a major outage. Every message carries a timestamp for the next update. Language stays plain, and components are named the way customers know them ("Dashboard" and "API Access", not "api-gateway-prod"). Share workarounds the moment they exist. If the incident could look like a security problem, say plainly that data is safe.
| Phase | Timing | What you post | Example |
|---|---|---|---|
| First acknowledgment | Within 15 min of confirmed impact | You are investigating, symptom in plain language | "We are investigating reports of slow checkouts." |
| Scope | 15-45 min | Affected features, workaround if one exists | "Checkout is unavailable. Orders placed before 9:00 UTC are safe." |
| Heartbeat | Every 30 min | Same status, next-update timestamp | "Still investigating. No new information. Next update in 30 minutes." |
| Resolution | When stable, then a follow-up | What happened, apology in proportion | "Service restored. Full postmortem by Friday." |
The heartbeat rule is the one teams resist, because posting "still investigating" feels like admitting failure. It is not an admission; it is the update. Customers left in the dark assume the worst, and poor communication tracks with churn. A repetitive update every 30 minutes tells people you have not abandoned them and absorbs the "is it fixed yet?" tickets that would otherwise bury support.
Four templates that cover any outage
Pre-write these in your status page tool so the first update of a real incident is a fill-in-the-blank, not a blank page. The "next update in" line goes in every single message: you are promising the update, not the fix.
- Investigating: "We are experiencing a service disruption. Our team is working to identify the root cause. Users may be affected by [impact]. Next update in 30 minutes."
- Identified: "We have determined that [problem]. [Impact] may be affected. We are working to [fix]. Next update in 30 minutes."
- Monitoring: "We have deployed a fix that [fix]. Users should now see [expected behavior]. We are monitoring to confirm. Next update in 30 minutes."
- Resolved: "[Issue] is resolved. We are sorry for [apology proportional to the actual impact]. A postmortem will be published by [date]."
Match the apology to the damage. A 20-minute blip earns "sorry for the interruption." A 28-hour outage earns more, plus a date for the review. Keep a fifth template for upstream failures: "We are experiencing a disruption caused by one of our infrastructure providers. We are monitoring their status and will update you within 30 minutes." Atlassian's Statuspage guidance suggests keeping this as its own template group.
Two jobs, two owners
The hour produces two things: the customer relationship and the evidence for your own SLA credit claim against the provider. If one person owns both, one gets dropped.
| Role | Owner | Job during the outage |
|---|---|---|
| Incident commander | Senior on-call | Runs the bridge, sets severity, approves public updates |
| Communications lead | Support or customer success lead | Posts status updates, answers the queue, keeps one voice |
| Evidence keeper | An engineer who is not fixing | Records UTC timestamps, incident IDs, region, resource IDs, error logs |
The evidence keeper matters because claims are adjudicated weeks later and the provider will ask you to prove impact: the incident ID from the status page, UTC timestamps, the region, your account or subscription IDs, screenshots of the errors. Capture it live or reconstruct it painfully from Slack history afterward. Tools that watch provider status down to the service and region level, such as UptimeAudit, record the timeline as it happens, which is exactly the reconstruction the evidence keeper would otherwise own.
And the claim is worth filing; put the reminder in the calendar the same day:
| Provider | Claim window | Credit tiers |
|---|---|---|
| AWS | 60 days after the billing cycle ends | 10% / 30% / 100% |
| Azure | 60 days after the month ends | 10% / 25% / 100% |
| Google Cloud | 30 days after the month ends | 10% / 25% / 50% |
| DigitalOcean | 30 days after the month ends | 5% / 10% / 30% |
A credit is a fraction of what the outage cost you in revenue. It is compensation, not recovery; the communication is the recovery. Full thresholds, evidence rules, and templates are in our SLA credit guide and evidence checklist.
After it is over: the postmortem and the awkward question
Publish the postmortem: what happened, when, what you changed, what changes next. It is the cheapest credibility you can buy after an outage.
Then the awkward question: do you owe your own customers credits? That is a contract question, not a feelings question. Your SLA commitment to a customer applies regardless of root cause unless your contract excludes third-party infrastructure failures. SaaS contract guidance from TOS Lawyer is blunt: the customer's contract is with you, not your cloud vendor, and providers often try to carve third-party outages out of the uptime calculation. Many MSP and SaaS contracts contain that carve-out. Some do not. Know which column yours sits in before a customer asks; the question always comes, and it comes angrier when you improvise.
Decide the policy now. If your contract does not exclude provider outages, the math bites: a 99.9% promise allows about 43 minutes of downtime per month, so a 28-hour upstream failure is a breach, full stop. Then pick your response: automatic credits, credits above a threshold, or case by case. Agreeing before a dispute is cheap. Negotiating after one is not.
Do this today
Open your status page tool and write the four templates from this post into it. Put a named communications lead on every on-call shift and add the evidence keeper role to your incident checklist. That is twenty minutes of work. The next provider outage is a when, not an if, and when it lands, the only open question is whether your customers hear it from you first.