The Other SLA: Support Response Times on AWS, Azure and Google Cloud
September 30, 2026
Every credit claim travels through a support case, and every support case travels on a clock of its own. The response clock is not the uptime clock: it pays no credits and it fixes nothing, but it decides how the first hours of an incident go, and how fresh the evidence is when the claim is drafted. The fastest commitments in the big three are genuinely fast, fifteen minutes for a critical case on AWS Enterprise and Google Premium, under an hour across Azure's paid tiers, and the entry tiers are slower than most teams assume. On Google Standard, the most important case category, P1, is not covered at all.
The response times, by top tier
| Provider, top tier | Critical case | High | Medium |
|---|---|---|---|
| AWS Enterprise | < 15 minutes | < 1 hour, production system down | < 4 hours, production impaired |
| Azure Unified Enterprise | < 1 hour, Severity A | < 2 hours, Severity B | < 4 hours, Severity C |
| Google Premium | 15 minutes, P1 | 2 hours, P2 | 4 hours, P3 |
The tiers below move the numbers, and the movement is large. AWS Business Support+ starts at 30 minutes for a business-critical case rather than 15. Azure Standard sits at under an hour for Severity A but gates Severity C to eight business hours. Google's middle tier takes an hour for P1 and four hours for P2, and Google Standard does not list a P1 response at all. For Azure, critical Severity 1 responses on Unified Enterprise drop to fifteen minutes for Azure products, one hour for everything else. AWS's Unified Operations tier adds an under-five-minute response from an Incident Management Engineer for the same critical category.
What the promise is actually made of
None of these are credit commitments, and none of them promise a fix. AWS's comparison page is explicit that it will make "every reasonable effort to respond" within the timeframes; Google's Technical Support Services Guidelines call the numbers "target initial response times", with the clock stopping at first contact. Resolution is a separate, uncommitted matter everywhere.
The severity drives everything, and you do not fully control it. Google may reclassify a priority it believes is incorrect, with determinations "final and binding", and P1 status carries an obligation to maintain continuous availability until resolution. Azure may downgrade the severity level if a customer cannot provide adequate resources or responses. The practical reading is that the response time is not a lever you pull by shouting P1; it is a commitment conditioned on the case actually being critical and on you engaging.
The gates matter too. Basic plans at AWS and Google carry no technical response at all. Azure's Developer plan caps at Severity C, with A and B unavailable. Google Standard skips P1 entirely. If the incident is critical, the plan tier is the difference between a quarter-hour and nothing at all.
The response clock pays no credits; it decides how the incident goes. Fifteen minutes buys a human on a critical case at AWS Enterprise and Google Premium, an hour is the paid standard at Azure, and on the entry tiers the most important category may not be covered at all. The claim clock and the response clock are different documents, and only one of them pays.
The two clocks in one incident
The response clock starts when the case is submitted. The credit clock started when the incident began, and it does not care how fast support answered: Google wants notification within 30 days, Azure within 60, AWS by the end of the second billing cycle after the incident. Different documents, different deadlines.
Where the response clock earns its keep is evidence. The support case is the incident's paper trail: case number, timestamps, the provider's acknowledgement, the engineer's questions and answers. That record correlates your logs with the provider's account of the same window, which is exactly the correlation a claim needs, as the evidence checklist lays out. And the fastest evidence is the easiest to collect: interval data, request IDs and error logs degrade the longer an incident fades into the past.
One more distinction closes the loop. If the provider's own failure caused your downtime, the money comes from the uptime SLA, never from the support plan. The support plan's value is the speed of the human, and the claim's value is the language of the SLA. Mixing the two expectations is how teams end up disappointed by both.
Filing well
Three habits get the most out of whatever plan you hold. First, write the severity honestly and lead with impact: what is down, since when, what it costs per hour, plus the request IDs and timestamps. An accurate critical classification survives review; an inflated one gets downgraded at the worst possible moment. Second, raise the case while the incident is still burning, even if your team is already recovering: the timestamped record is future claim ammunition, and it costs nothing to file. Third, keep the engagement going. Azure's downgrade clause centres on resources and responses, and Google's P1 condition demands availability until resolution; the plans reward teams that stay in the conversation.
None of this replaces redundancy. But once an incident happens, the response clock and the credit clock run side by side, and the teams that respect both collect the most from the paperwork. UptimeAudit stays on the credit side of that line, watching the big four's health feeds and drafting the claims these documents actually pay.