Part VI · Chapter 11 · Choosing · lesson 6
What the availability agreement excludes, in its own words
14 min
Builds on You promised three nines. That is nine hours a year and Which link in your chain owns your downtime
Part VI · Chapter 11 · Choosing · lesson 6
14 min
Builds on You promised three nines. That is nine hours a year and Which link in your chain owns your downtime
In March your service was unusable for two hours and forty minutes. The provider's product page says four nines. You filed a claim.
Ninety of those minutes were refused, because the service was responding slowly rather than not responding. The remaining seventy were accepted, and the remedy was a ten percent credit against one month of one service's charges — roughly the price of taking the team to lunch. Your own cost of those minutes was three orders of magnitude higher.
Nobody misled you. You had not read the agreement.
An availability agreement is a short document and only five parts of it matter. Read them in this order, because the first one voids more claims than the other four combined.
One: the definition of unavailable. This is the whole document. Typically it means a total loss of external connectivity or a total failure of the API in a region, measured in whole minutes, with every request in that minute failing. Slow is not unavailable. An elevated error rate is not unavailable. Partial function loss is usually not unavailable. The definition is narrow because it has to be objectively measurable, and most real degradations are not objectively anything.
Two: the measurement unit and window. A monthly uptime percentage, per region, per service, computed from the provider's own measurements over a calendar month. Three consequences. A two-day outage and twenty separate two-minute outages can land in the same credit tier. An outage spanning midnight on the last day of the month is split across two windows and may clear neither threshold. And the provider computes the number, from their instrumentation, not yours.
Three: the architectural preconditions. The headline percentage is conditional on how you deployed. A compute agreement typically offers its best figure only to a workload running across two or more availability zones in a region, with a materially lower figure — and a separate, lower credit tier — for a single instance. Deploy into one zone and the four-nines number was never yours to claim.
Four: the exclusions. Your configuration, your software, third-party software and services, anything the provider judges outside their reasonable control, beta and preview features, free-tier usage, suspended accounts, and usually anything caused by you exceeding a quota. Read that list and ask honestly what caused your last three incidents.
Five: the remedy and the claim procedure. A service credit against future charges for the affected service, capped at a percentage of what you paid for that service in that month. Not cash, not consequential loss, and not automatic: you file, with timestamps and evidence, within a deadline measured in billing cycles, and the provider decides. Miss the deadline and the credit is gone.
Predict
The tiers below are the shape a major compute agreement uses. The exact boundaries vary by provider and by service and belong in the dated caveat, but the structure is near-universal and the structure is the point.
MONTHLY UPTIME PERCENTAGE SERVICE CREDIT
less than 99.99% but >= 99.0% 10% of the monthly charge
less than 99.0% but >= 95.0% 30%
less than 95.0% 100%
WHAT EACH THRESHOLD IS, IN MINUTES OF A 30-DAY MONTH
99.99% 4.3 min downtime budget before any credit is owed
99.0% 7.2 h downtime before the credit rises to 30%
95.0% 36 h downtime before the credit reaches 100%
A WORKED CLAIM
monthly spend on the affected service $8,000
confirmed unavailable minutes 70 -> 99.84% uptime
credit tier 10%
credit received $ 800 (against a future bill)
your own revenue lost in those 70 minutes $ 95,000 (illustrative)
ratio 1 : 119
Three things to take from that block. The credit is a percentage of what you paid them for that one service, so it is bounded by your spend rather than by your loss, and the ratio gets worse the more successful your business is. It is a credit against future charges, so it is worth its face value only if you keep buying. And to reach the hundred percent tier you must have been down for well over a day, at which point the full month's refund is irrelevant beside what else has happened to you.
The conclusion is not that agreements are a swindle. It is that an availability agreement is the price the vendor is willing to pay for being wrong, capped at your bill — not a prediction of uptime, and not insurance. Reading it as a prediction is the error that leads to designing against it.
Not the same thing
A contractual threshold, below which the provider owes you a service credit for the affected service in that month.
The fraction of user-visible attempts that succeeded within an acceptable time, over whatever window you care about.
Which is which? Put each one on a side.
Total loss of connectivity to every instance in a region for eleven minutes, acknowledged by the provider
An error rate of two percent for three hours, with the service responding throughout
Six hours down after your own security group change
Your single-zone deployment loses its availability zone for two hours
Provider-confirmed failure of the managed queue's API in your region for forty minutes
Latency rising tenfold while every request still succeeds
Four hours where no new capacity could be provisioned while running capacity served normally
An expired certificate on a dependency inside your own account
Count the sides. Three of those eight episodes touch the agreement and five do not, and the five include the ones most likely to happen to you. That ratio is the whole argument of this lesson: the document covers a minority of your downtime by design, and it is not trying to hide that.
Five independent reasons, and they compound.
The practical consequence for design: never design to a published percentage. Measure your own availability at the edge your users touch, derive an error budget from what the business can actually tolerate, and treat every dependency's agreement as information about the vendor's confidence rather than as a guarantee you can inherit. The agreement's genuine uses are narrower and real — comparing two vendors' confidence in the same service class, as an input to a procurement negotiation, and as the thing you quote when asking for a negotiated agreement with teeth.
Check
Every clause above is void when the cause is on your side of the line. Your configuration, your deploy, your code, your quota, your certificate, your architecture that put everything in one availability zone. That is not a loophole — a vendor cannot underwrite choices they do not make — but it has a consequence worth stating plainly, because it inverts how most teams use these documents.
For most services, self-inflicted causes dominate the downtime. Bad deploys, configuration changes, exhausted limits, expired credentials, a migration run at the wrong time. If that is true of you, then the agreement you spent an afternoon reading governs the minority of your outage minutes, and the percentage on the product page has almost no bearing on what your users experience.
So the time spent on availability agreements should be roughly proportional to how much of your downtime is actually the provider's, which you can only know by classifying your own incidents. Do that first. If provider-caused minutes turn out to be a small fraction of the total, the leverage is in deploy safety, change control and limit monitoring, and reading another agreement is procrastination with a spreadsheet.
And know which direction the exclusion cuts when you are the vendor: the same clause that denies your claim is the one protecting you from a customer's own misconfiguration, and you will want it worded just as narrowly.