Is Your Cloud Provider Down? What to Do in the First 60 Minutes
July 20, 2026
Your dashboards are red. Deploys are hanging. Support tickets are trickling in. Somewhere in the back of your mind a question forms: is this us, or is this them?
The next 60 minutes decide two things: how fast you recover, and whether you'll get the SLA credits you're owed afterward. Most teams handle the first and completely fumble the second. Here's the runbook for both.
The single most important takeaway: the outage is only half the hour. The credits are decided by what you capture while it is live and whether you file before the deadline. Most teams fumble exactly those two steps, and the provider will not chase you.
The first 60 minutes at a glance
| Time window | What to do | Why it matters |
|---|---|---|
| Minutes 0-10 | Confirm it is really the provider: check the status page but treat it as lagging, corroborate externally, and scope the failure to service and region | Every later step, including the SLA claim, depends on getting the scope right |
| Minutes 10-30 | Protect the system: failover if you are multi-region, communicate if single-region, freeze deploys on control-plane issues | You recover faster and avoid making the incident worse |
| Minutes 30-45 | Capture the evidence: UTC timestamps, error screenshots, resource IDs, and the provider's incident ID | Claims are adjudicated weeks later and you must prove impact |
| Minutes 45-60 | Set the deadline trap: calendar reminder and ticket assigned to a named human | Claim windows run 30-60 days and are the most commonly missed step |
Minutes 0-10: Confirm it's actually the provider
Before you failover anything or wake anyone up, establish where the failure lives.
- Check the provider's status page, but treat it as a lagging indicator. Providers routinely take 15-45 minutes to acknowledge incidents their customers detected in minute one. Bookmark the live trackers instead:
- AWS status, health-dashboard data plus our own probe checks
- Azure status
- Google Cloud status
- DigitalOcean status
- Corroborate externally. Downdetector, X/Twitter search for "AWS down", and your own synthetic checks from a different network. If your office ISP is the thing that's down, a provider failover accomplishes nothing.
- Scope it precisely. Which service? Which region? "AWS is down" is almost never true: "EC2 API errors in us-east-1" is the shape of reality. Every later step, including the money step, depends on getting this scope right.
Minutes 10-30: Protect the system
With scope established, triage by blast radius:
- If it's regional and you're multi-region: initiate your failover runbook. This is the scenario you paid for.
- If it's regional and you're single-region: resist the urge to improvise a cross-region migration mid-incident. For most workloads, the provider recovers faster than you can re-platform under fire. Communicate instead: status page update, in-app banner, support macro.
- If it's a control-plane-only issue (common with IAM, EC2 API, and console outages): your running workloads often keep working. Freeze deploys and autoscaling changes, and don't mistake "can't make changes" for "everything is down."
- Write down the decision and the time. Not for the postmortem, for the claim (see below).
Minutes 30-45: Capture the evidence you'll need in six weeks
This is the step everyone skips and everyone regrets. SLA credit claims are adjudicated weeks later, and the provider's support team will ask you to prove impact. Their status page acknowledgment is not, by itself, a claim.
While the incident is live, capture:
- Timestamps in UTC of when your systems first saw errors and when they recovered. Your monitoring tool's incident record is ideal; a Slack timestamp trail works too.
- Error evidence: screenshots of 5xx responses, failed health checks, API error rates from your APM or load balancer logs.
- Affected resource identifiers: account/subscription/project IDs, region, instance or cluster IDs. You will be asked for exactly these.
- The provider's incident ID or status-page URL once they publish it, screenshot it; incident pages sometimes get edited or consolidated later.
Five minutes of screenshotting during the fire saves an hour of archaeology afterward, and is frequently the difference between an approved claim and a stalled one.
Minutes 45-60: Set the deadline trap
The outage will end. The adrenaline will fade. And then the claim window starts quietly ticking:
| Provider | Claim deadline |
|---|---|
| AWS | within 60 days of the end of the billing cycle |
| Azure | within 60 days of the end of the month |
| Google Cloud | within 30 days of the end of the month, the shortest and most commonly missed |
| DigitalOcean | within 30 days of the end of the month |
Before you close the incident channel: create the calendar reminder, the Jira ticket, whatever your org actually looks at. Assign it to a named human. "We'll file it later" is how four-figure credits evaporate: the thresholds are low enough that even a sub-hour blip can qualify (at a 99.99% SLA, about 4½ minutes of downtime in a month is technically a breach).
Then, when things are calm, work out the credit tier. Our pillar guide has the per-provider thresholds and submission channels: How to Claim SLA Credits from AWS, Azure, GCP, and DigitalOcean.
Or skip steps 3 and 4 entirely
The reason teams miss credits isn't laziness, it's that evidence capture and deadline tracking are boring chores bolted onto an already stressful hour. So we automated them. UptimeAudit watches the big four providers' status pages and health endpoints down to the service and region level, records the incident timeline as it happens, and when observed downtime crosses your provider's SLA threshold it drafts the credit claim for you, pre-filled with your account details, the evidence, and the deadline counted down in your dashboard. You review and submit; the provider decides the outcome, as always.
Next outage, spend your 60 minutes on your customers. Let the paperwork take care of itself.