SLA Calculator: Uptime Downtime, Composite SLA and Service Credits
Add every service a request depends on and see what your real combined availability is, how much downtime that allows, and what credit a provider owes you when it misses. Serial dependencies multiply, redundant ones do not.
Composite SLA calculator
LiveDependency chain
Set copies above 1 for a service you run redundantly, where any one copy is enough to serve the request.
What an SLA calculator does
An SLA calculator turns a service level agreement into the three numbers you actually need: how much downtime the percentage allows, what your combined availability comes to once every dependency in the chain is counted, and what service credit you can claim when a provider misses its commitment. Services that must all be working multiply together, so a chain is always less available than its weakest link. Redundant copies of the same service combine the other way and push availability up.
The reason this needs a calculator rather than a rule of thumb is that the arithmetic runs against intuition. People read a stack of services all promising 99.99% and assume the whole system is a four nines system. It is not. Four required services at 99.99% come to 99.96%, which allows about 17 minutes of downtime a month instead of 4. Nothing in that stack is broken or misconfigured. That is simply what the contract adds up to.
The second half of the job is the money. When a provider does miss its commitment, the credit is rarely automatic and is usually a percentage of that one service bill rather than anything resembling the cost of the outage. Knowing which band you fell into, and that most providers put a deadline on the claim, is the difference between a credit and a shrug.
The two formulas, side by side
SERIAL (all must work) A = a1 x a2 x ... x an availability goes DOWN REDUNDANT (any one is enough) A = 1 - (1 - a)^k availability goes UP
Almost every mistake in SLA maths is one of these two being used where the other belongs. A dependency chain is serial. A pair of regions behind a failover is redundant. Most real systems are a chain that contains a few redundant links.
The most commonly published SLA formula is the wrong one
Multiply for dependencies, not for redundancy
Search for how to calculate a composite SLA and a majority of the results hand you a single formula, 1 minus (1 minus a1) times (1 minus a2), and then apply it to a virtual machine and a database that a request must pass through in sequence. That is the redundancy formula. Used on a dependency chain it does not just skew the answer, it inverts the direction of the effect: it reports that adding a dependency made the system more available.
Microsoft's Well-Architected Framework states the correct rule for a chain in one line: a composite value is a product of the contributing factors, and it gives 99.95% times 99.99999% as its worked example. Multiplication, not the complement. The table below runs the same pair of services both ways.
The gap is not academic. It is the difference between an architecture review approving a design that clears its target and approving one that cannot reach it in any month where anything at all goes wrong. Nobody finds out until the quarter is over.
A VM at 99.9% and a database at 99.99%, both required
- Correct, multiplied
- 99.89%
- 47 minutes 31 seconds of allowed downtime a month
- Redundancy formula misapplied
- 99.99999%
- 0.3 seconds a month
Same two services, same two published numbers. One answer is roughly nine thousand times more forgiving than the other, and it is the one most search results will give you.
What each level buys you
How much downtime each SLA level permits
These figures use a 30 day month and a 365 day year, which is how cloud providers define a monthly uptime percentage and how Azure publishes its own allowance table. If you want the same arithmetic across more levels and periods, including calendar month variation, the uptime calculator covers 12 availability levels and five periods.
| Availability | Per day | Per week | Per month | Per year |
|---|---|---|---|---|
| 99% | 14 minutes 24 seconds | 1 hour 40 minutes | 7 hours 12 minutes | 3 days 15 hours |
| 99.5% | 7 minutes 12 seconds | 50 minutes 24 seconds | 3 hours 36 minutes | 1 day 19 hours |
| 99.9% | 1 minute 26 seconds | 10 minutes 5 seconds | 43 minutes 12 seconds | 8 hours 45 minutes |
| 99.95% | 43.2 seconds | 5 minutes 2 seconds | 21 minutes 36 seconds | 4 hours 22 minutes |
| 99.99% | 8.6 seconds | 1 minute | 4 minutes 19 seconds | 52 minutes 34 seconds |
| 99.999% | 0.9 seconds | 6 seconds | 25.9 seconds | 5 minutes 15 seconds |
Read down the monthly column and the practical meaning of each step becomes obvious. At 99.9% you can absorb a bad deploy and roll it back inside the lunch hour. At 99.99% the entire monthly budget is four minutes, which is less time than most teams take to acknowledge a page, so detection and failover have to be automatic. The jump from 99.95% to 99.99% is where human response stops being a viable recovery plan.
Read from each provider's own SLA page, August 2026
What providers actually pay when they miss
| Provider | Commitment | Model | Credit |
|---|---|---|---|
| AWS EC2, region levelApplies when instances run concurrently across two or more availability zones in the same region. | 99.99% | Step tiers | Below 99.99% and at or above 99.0%: 10%. Below 99.0% and at or above 95.0%: 30%. Below 95.0%: 100%. |
| AWS EC2, single instanceAWS credits a single instance automatically, with no claim required, when it is unavailable for more than six minutes of a clock hour. | 99.5% | Step tiers | Below 99.5% and at or above 99.0%: 10%. Below 99.0% and at or above 95.0%: 30%. Below 95.0%: 100%. |
| Google Cloud SQL, Enterprise PlusCredit must be claimed with Google support within 30 days of becoming eligible or the right to claim is forfeited. | 99.99% | Step tiers | 99.0% to below 99.99%: 10%. 95.0% to below 99.0%: 25%. Below 95.0%: 100%. |
| Google Cloud SQL, EnterpriseNote the ceiling. The Enterprise edition caps at 50% where Enterprise Plus reaches 100% for the same outage. | 99.95% | Step tiers | 99.0% to below 99.95%: 10%. 95.0% to below 99.0%: 25%. Below 95.0%: 50%. |
| Cloudflare, Business planCredits are capped at one month of cumulative total monthly service fees in any 12 month period. | 100% | Pro rata formula | Service credit equals outage period minutes multiplied by the affected customer ratio, divided by scheduled availability minutes. |
Two things stand out once the schedules are lined up. The first is that a credit is a percentage of the bill for the one service that failed, not of your total invoice and certainly not of your losses. A 10% credit on a database that costs 400 dollars a month is 40 dollars, against an outage that may have cost you a great deal more.
The second is that the ceiling moves with the tier you bought. Google Cloud SQL Enterprise Plus can return 100% of the monthly charge for a severe outage. The plain Enterprise edition, for the identical outage, stops at 50%. Cloudflare takes a different route again, committing to 100% uptime without qualification and then calculating credits from outage minutes rather than from bands, capped at one month of fees across any 12 month period.
Deadlines matter as much as percentages. Google requires notice to support within 30 days of becoming eligible, after which the right to claim is forfeited. AWS is the exception worth knowing: for a single EC2 instance unavailable more than six minutes of a clock hour, the credit is applied automatically with no claim at all.
Three credit models, not one
- Step tiers. AWS and Google. You land in a band based on monthly uptime and get a fixed percentage back. Simple, and it means a 99.98% month and a 99.1% month pay identically.
- Pro rata formula. Cloudflare. Credit scales with the actual outage minutes and how many customers were affected, so a short blip pays a small amount rather than nothing.
- Claim required or automatic. Cutting across both: most providers make you file, on a clock. AWS self credits certain instance level failures.
Under step tiers there is no reward for a near miss. Falling from 99.99% to 99.98% pays the same 10% as falling to 99.1%.
Azure publishes its credit tiers in the Service Level Agreements for Microsoft Online Services document rather than on a per service web page, so we do not reproduce Azure credit percentages here. We would rather name the gap than print a number we could not read from the source today.
The number covers less than you think
An SLA does not guarantee the service as a whole
Before any published percentage goes into your calculation, it is worth reading what the agreement counts as available. Microsoft is unusually direct about this: its guidance says outright that SLAs do not guarantee an offering as a whole, and that anything not mentioned explicitly should be treated as best effort by the platform.
The examples it gives are instructive. Azure App Service counts as available when it returns a 200 status in a given use case, which does not extend a financially backed guarantee to features like authentication or slot switching. Azure Front Door commits 99.99% to successful HTTP GET operations under fairly specific conditions, and that narrow case does not cover caching, routing rules or the web application firewall.
So if your application depends on a feature that sits outside the covered use case, the honest input to your composite calculation is lower than the published figure. That is exactly what Microsoft's own reference example does, and it is worth copying: take the published number, then adjust it down for the parts you rely on that the contract does not actually promise.
Microsoft's own worked example
Its reference workload takes four Azure services, adjusts two of them downward for uncovered risk, and multiplies:
| Front Door | 99.99 to 99.98 |
| Container Apps | 99.95 |
| SQL Managed Instance | 99.99 to 99.80 |
| Private Link | 99.99 |
| Composite | 99.72 |
Adding budgets for code defects, configuration and deployments brings the final objective to 99.45% a month, roughly four hours. Then the business sets the customer facing SLA at 99.90%, a stricter promise than engineering predicts, which Microsoft describes as a calculated risk taken deliberately.
A number on a page is not a measurement
You cannot claim a credit you cannot evidence
Every credit schedule above puts the burden of proof on the customer. You are expected to supply incident times and evidence of unavailability, inside a window, and the provider validates that against its own monitoring. If your only record of the outage is a Slack thread and a memory of when things felt slow, the claim is difficult to make and easy to decline.
This is the practical reason to run checks from outside your own infrastructure. An external monitor timestamps the first failed check and the first recovered one, from several regions at once, which is what turns an outage into a defensible duration. It also gives you the other half of the picture: your own measured availability, next to the composite figure this calculator produced from the contracts.
Uptimehub runs HTTP, API, SSL, DNS, TCP port and cron heartbeat checks from six regions, with auto retry from a second region before anything alerts, so a single blip does not enter the record as an outage. SLA monitoring tracks measured availability against the target you set, and the same checks drive a branded status page your customers can read during the incident.
Three related but different questions
- What does the contract add up to? This page. Composite SLA across dependencies, plus credits.
- What does a percentage mean in minutes? The uptime calculator, across 12 levels and five periods.
- How much of the budget have I actually spent? An error budget, measured continuously rather than computed once.
Questions
Common questions about SLA calculations
How do you calculate a composite SLA?
Multiply the availability of every service the request has to pass through. Two components at 99.9% and 99.99% give 0.999 times 0.9999, which is 99.89%, not 99.9%. The result is always lower than the weakest single component, because any one of them failing takes the whole request down. Redundant copies of one service use a different formula and raise availability instead.
Why is my composite SLA lower than every individual SLA?
Because failures add up. In a chain where every component is required, the chance the whole path works is the product of each component working, and multiplying numbers below one always produces something smaller. Four services at 99.99% each come to 99.96%, which is 17 minutes of allowed downtime a month rather than the 4 minutes any one of them promises.
What is the difference between an SLA and an SLO?
An SLA is a contract with financial consequences if you miss it. An SLO is an internal target you set to stay safely ahead of that contract. Microsoft draws the same distinction in its Well-Architected Framework: the SLA has legal and financial implications, while the SLO exists so teams can judge whether current downtime is still within tolerable limits.
How are SLA service credits calculated?
Most providers use step tiers. You fall into a band based on your monthly uptime percentage and receive a fixed percentage of that month bill back, commonly 10% for a small miss and 100% for a severe one. Cloudflare instead uses a pro rata formula based on outage minutes. Credits apply to the affected service only, not the whole invoice.
Do service credits cover the cost of downtime?
Almost never. A 10% credit on a service that costs a few hundred dollars a month is worth tens of dollars, while the revenue and support cost of the same outage is usually far larger. Credits are a contractual signal, not compensation. Most agreements also cap total credits, and Cloudflare states that cap explicitly at one month of fees per 12 month period.
Does adding a second region improve my SLA?
Yes, and by more than most people expect, provided the regions genuinely fail independently and you can actually fail over. Two independent copies of a 99.9% service reach 99.9999%, because both have to fail at the same time for you to be down. That is the redundancy formula, and it is the reason every published five nines commitment is a multi region one.
Does an SLA cover the whole service?
No, and this is the most commonly missed detail. Microsoft states plainly that its SLAs do not guarantee an offering as a whole. Azure Front Door commits to successful HTTP GET operations, so caching, routing rules and the web application firewall sit outside the number. Read what the agreement defines as available before you put its percentage in your own calculation.
How much downtime does a 99.9% SLA allow?
On the 30 day month that cloud SLAs use, 99.9% allows 43 minutes 12 seconds a month, about 1 minute 26 seconds a day, and 8 hours 45 minutes a year. Moving to 99.95% halves that to 21 minutes 36 seconds a month. Each additional nine divides the allowance by ten.
Keep reading
Related pages
Uptime calculator
Downtime allowance across 12 availability levels and five periods, both directions.
99.999% uptime
What five nines costs to run, and why every published five nines SLA is multi region.
SLA monitoring
Track measured availability against your target and evidence it when you need to.
What is an error budget
Turning an availability target into a spendable budget, with burn rate thresholds.
99.99% uptime
Four nines across nine periods, and why check interval decides if you can detect it.
Monitoring pricing compared
Verified prices and the five billing models vendors use, with the hidden costs.
Measure the availability you are actually getting
Checks from six regions, auto retry before alerting, and a branded status page included. Your SLA is a promise. This is the evidence.