A founder asks for 99.99% uptime in a customer contract. Their product runs on two EC2 instances, one Postgres database, S3 for uploads, Twilio for login codes, and whatever the team deployed on Friday. Every one of those has a decent number attached to it. None of them is 99.99%, and together they are well below the worst of them.
It is one of the most common reliability mistakes in early contracts, and it is arithmetic, not engineering. When a request needs five things to be up, its availability is the product of five availabilities, and multiplying numbers below one always gives you a smaller number.
The contrast I keep in mind comes from my own work. EMPRO, a property platform I built alone, ran at 99.9% uptime through launch and handover, largely because its architecture was deliberately boring: one Node service, one database, nothing clever. At Acefone, a single WhatsApp conversation touches Meta's Cloud API, which does not publish an uptime SLA at all. Both are normal. What matters is knowing which situation you are in before you sign something.
What one nine buys you
Uptime percentages hide how different they are. 99.9% and 99.99% look almost the same on a slide. One allows nearly nine hours of downtime a year; the other allows under an hour.
A useful habit: whenever someone says a number of nines, translate it into minutes a month before discussing it. "Four nines" becomes "four minutes and twenty-three seconds a month, including the deploy that goes wrong". That conversation goes differently.
Dependencies multiply
If a request needs services A, B and C to all be up, the chance it succeeds is the chance A is up, times the chance B is up, times the chance C is up.
composite = A × B × C × …
0.9999 × 0.9995 × 0.999 × 0.9995 × 0.999 = 0.9969 → 99.69%Here is that same chain as a picture. Every box is a published SLA or an honest guess, and every one of them is individually respectable.
quick check
A request depends on three services in series, each with a 99.9% SLA. What is the composite availability?
0.999 × 0.999 × 0.999 is about 0.997, so 99.7%. That is roughly 2 hours 11 minutes of expected downtime a month, three times what each service allows on its own.
Redundancy is the only thing that adds nines
Series is "need both". Redundancy is "need either". If you run two copies of something and a load balancer can send traffic to whichever is healthy, the request only fails when both copies are down at the same moment. So instead of multiplying availabilities, you multiply the chances of failure.
one copy: a
n copies: 1 − (1 − a)ⁿ
two at 99.5%: 1 − 0.005² = 0.999975 → 99.9975%
The catch is the word "independent". Two instances in the same availability zone, running the same build, reading the same config, are not independent. When the zone has a bad day, or the deploy has a bad line, they fail together and the formula stops describing reality. This is why cloud providers only publish their best numbers for deployments spread across zones.
Work it out for your own stack
Put in every dependency a request needs to succeed. Use a published SLA where one exists, and an honest guess where it does not. The presets are the numbers from the providers' own SLA pages.
calculator · composite availability
What can you actually promise?
| dependency on the request path | monthly uptime % | redundant copies | |
|---|---|---|---|
Assumes failures are independent, which is the optimistic case: two services in the same region often fail together. Redundant copies are treated as active-active, where any one copy can serve. Published SLAs are the level below which a provider pays credits, not a forecast.
Two rows people forget: DNS, and whatever handles login. If your users sign in through a third-party auth provider, that provider is on the path of every authenticated request. It belongs in the chain.
The published numbers
These are the monthly uptime commitments from each provider's SLA page as of September 2026. Read them as the level at which the provider starts paying you credits.
| Service | Commitment | Notes |
|---|---|---|
| AWS EC2, instances in 2+ zones | 99.99% | region-level; a single instance is 99.5% |
| AWS RDS, Multi-AZ | 99.95% | Single-AZ is 99.5% |
| AWS S3 Standard | 99.9% | the threshold where credits begin |
| Google Compute Engine, multi-zone | 99.99% | a single instance is 99.9% for most machine families |
| Google Cloud SQL Enterprise Plus, HA | 99.99% | Enterprise edition HA is 99.95% |
| Google Cloud Storage, regional Standard | 99.9% | multi-region Standard is 99.95% |
| Azure VMs, availability set | 99.95% | |
| Twilio APIs | 99.95% | 99.99% on Enterprise Edition |
| Stripe | none published | |
| WhatsApp Cloud API | none published | Meta says it does not offer commercial SLAs for uptime or latency |
Notice the pattern. The numbers that look like four nines all come with a condition: across zones, high-availability configuration, enterprise tier. The default, single-box version of almost everything is 99.5% to 99.9%.
An SLA is a refund policy
This is the part that surprises people outside infrastructure. When AWS promises 99.99%, it is not predicting that EC2 will be down for four minutes a month. It is saying that if availability falls below that line in a given month, you can claim service credits against that service's bill.
That has two consequences. First, the credit is capped at what you paid for that service, which for most startups is small next to what an outage costs them. Second, the SLA says nothing about latency, partial failures or a service that is technically up and returning errors to half your requests. Your customers will not make that distinction. They will say you were down.
So when you pass an SLA on to your own customers, remember that you are underwriting the difference. If your provider pays you a 10% credit on a $200 database bill and your contract pays your customer back a month of a $5,000 subscription, the arithmetic of the refund is also yours.
What the arithmetic flatters
The composite number is the optimistic case. Four things make reality worse:
- Correlated failures. A region outage takes out the app servers, the database and the cache at the same time. The formula assumes they fail separately, so it counts that one event as three small ones.
- Your own changes. Deploys, migrations and config changes cause more downtime in young systems than any cloud provider does. If you have no number for it, 99.9% is a generous starting guess for a team that ships daily.
- Slow is the new down. A dependency that answers in 30 seconds is up by the SLA's definition and down by your user's.
- The dependencies you forgot. DNS, certificates, the email provider for password resets, the payment provider at checkout. Each is a multiplier you did not write down.
Buying nines without buying servers
The cheapest nine usually does not come from redundancy. It comes from taking a dependency off the critical path, so that when it fails, the request still succeeds.
- Queue what can wait. If Twilio is down, write the SMS to a queue and send it when Twilio is back. The signup succeeds, and Twilio drops out of that request's chain. The same pattern needs backpressure and a plan for the backlog, or the recovery becomes its own outage.
- Serve something stale. A product page that shows five-minute-old prices is available. A product page that waits for a live price service is only as available as that service.
- Make retries safe. Redundancy and retries only help if doing something twice does no harm. That is what idempotency buys you.
Each of these removes a multiplier. Removing a 99.9% dependency from the chain is worth the same as adding a nine to it, and it is usually a week of work instead of a second region.
questions people ask
What does 99.9% uptime mean in hours?
About 8 hours 46 minutes of downtime a year, or 43 minutes 50 seconds in an average month.
What is the difference between 99.9% and 99.99% uptime?
Ten times less downtime. 99.9% allows 8 hours 46 minutes a year; 99.99% allows 52 minutes 36 seconds.
How do you calculate a composite SLA?
Multiply the availability of every dependency a request needs. For redundant copies of one dependency, first work out one minus the product of their failure rates, then use that in the chain.
Does the WhatsApp Cloud API have an SLA?
No. Meta's support documentation says it does not currently offer commercially available service level agreements for uptime or latency.
Is AWS EC2 99.99% available?
Only at the region level, for instances spread across two or more availability zones. A single EC2 instance has a 99.5% commitment.
The short version
Write down every service a request needs. Multiply their availabilities. Add your own deploys as a line, because they belong there. The result is the most you can promise, and you should promise less, with maintenance windows and measurement defined in writing.
If the number is too low, you have two levers. Redundancy adds nines, but only when the copies fail independently. Taking a dependency off the critical path removes a multiplier altogether, and it is almost always the cheaper of the two.