Security & Infrastructure

Uptime SLA Calculator: Optimize Service Levels & Boost Reliability

Turn nines into real downtime budgets.

This SLA uptime calculator converts an availability percentage into the downtime it actually allows — per day, week, month and year. 99.9% ('three nines') permits 43 minutes 50 seconds of downtime per month; 99.99% permits 4 minutes 23 seconds; 99.999% ('five nines') permits just 26 seconds. Enter your target, or enter the outage minutes you have already had, to see how much error budget is left.

Per day

1.4 min

Per week

10.1 min

Per month (30d)

43.2 min

Per quarter

2.2 h

Per year

8.8 h

Join the Veojson dispatch

Get the SRE reliability starter kit with SLO templates and alerting thresholds.

One email, no spam, unsubscribe any time.

About this tool

An SLA percentage is abstract until you convert it into minutes. Three nines allows about 43 minutes of downtime a month; four nines allows just over four. That gap is the difference between manual and automated recovery.

Error budgets

The downtime you are allowed is a budget. Spend it deliberately on deploys and maintenance rather than discovering it during an incident.

Composite availability

Chained dependencies multiply. Five services at 99.9% each give roughly 99.5% end to end.

What each 'nine' actually costs you

Every additional nine cuts your permitted downtime by a factor of ten and typically multiplies the engineering cost by far more. 99% availability allows over seven hours of downtime a month, which a single overnight maintenance window consumes. 99.9% allows 43 minutes — achievable with a well-run single-region deployment, health checks and fast rollbacks. 99.99% allows 4 minutes and 23 seconds, which is less than most human responses to a page, so it requires automated failover and multi-AZ redundancy. 99.999% allows 26 seconds a month, meaning no human can be in the recovery path at all: it demands multi-region active-active infrastructure, and it is undermined by any single dependency that is less available than the target.

Error budgets: the practical way to use an SLA

Turn the allowance into a budget. If your SLO is 99.9% monthly, you have 43 minutes 50 seconds to spend. Deployments, migrations and experiments draw it down. While budget remains, ship aggressively; when it is exhausted, freeze feature releases and spend the sprint on reliability. That single rule converts a contractual number into a day-to-day engineering decision, and it stops the two failure modes of SLAs: reckless shipping and total risk aversion.

Availability of a chain of dependencies

When services depend on each other in series, availabilities multiply. Three components at 99.9% each give 0.999³ = 99.7%, or about 2 hours 11 minutes of downtime a month — worse than any individual part. This is why adding a component always lowers availability unless it is redundant. Redundancy works the other way: two independent replicas at 99% each fail simultaneously only 0.01% of the time, giving 99.99% combined, provided the failures really are independent and not sharing a region, a deploy pipeline or a certificate.

What to define before signing an SLA

The percentage is the least contentious part of the contract. Define what counts as downtime (full unavailability, or degraded latency too?), how it is measured (your monitoring or the customer's?), the measurement window (calendar month or rolling 30 days — a rolling window is materially stricter), and the exclusions (planned maintenance, force majeure, customer-caused faults, third-party provider outages). Then set the remedy: service credits are standard, typically 10% of the monthly fee for a missed 99.9% and rising in tiers. Always set your internal SLO tighter than the contractual SLA — commit to 99.9% externally while targeting 99.95% internally — so you have warning before you owe credits.

Measuring uptime honestly

Measure from outside your own infrastructure, from several regions, against a health endpoint that exercises the real dependency chain rather than returning a static 200. Check at least once a minute; a five-minute interval cannot detect the four-minute outage that breaches a 99.99% SLA. Record partial outages as partial: if 20% of requests failed for 30 minutes, that is 6 minutes of downtime-equivalent, and request-based measurement is fairer to both sides than a binary up/down flag.

Uptime percentage to allowed downtime

AvailabilityPer dayPer weekPer month (30d)Per year
99%14m 24s1h 40m 48s7h 12m3d 15h 36m
99.5%7m 12s50m 24s3h 36m1d 19h 48m
99.9% (three nines)1m 26s10m 5s43m 50s8h 45m 57s
99.95%43s5m 2s21m 55s4h 22m 58s
99.99% (four nines)8.6s1m 1s4m 23s52m 36s
99.999% (five nines)0.9s6s26s5m 15s
99.9999% (six nines)0.09s0.6s2.6s31.6s
Monthly figures use a 30-day month. A 31-day month is slightly more generous, a 28-day February slightly stricter — worth pinning down in the contract.

Combined availability of dependencies

ArchitectureCalculationEffective availability
2 services in series at 99.9%0.999 × 0.99999.80%
3 services in series at 99.9%0.999³99.70%
5 services in series at 99.9%0.999⁵99.50%
2 redundant replicas at 99%1 − 0.01²99.99%
2 redundant replicas at 99.9%1 − 0.001²99.9999%

How to use Uptime SLA Calculator

  1. 1

    Open Uptime SLA Calculator

    Everything runs on this page — there is nothing to install and no account required to use the free features.

  2. 2

    Add your input

    Paste or enter your values in the panel above. The tool updates as you type, so you can iterate quickly.

  3. 3

    Review the output

    Check the result, copy it with one click, and adjust the options until it matches what your system expects.

  4. 4

    Take it further

    Use the security & infrastructure tips below to make the result production-ready, then unlock the gated extras via the form above.

Best practices

  • Treat every result as a snapshot — configuration drifts, so re-check after each deploy.
  • Fix the highest-impact finding first rather than chasing a perfect score.
  • Apply changes at the shared layer (proxy, CDN, base image) so every service inherits them.
  • Document what you changed and when; auditors and future teammates will ask.

Uptime SLA Calculator — Why it matters

Infrastructure and security misconfigurations are among the most common root causes of real incidents, and almost all of them are cheap to fix once visible.

Leaving them unaddressed means failed audits, blocked enterprise deals, and avoidable exposure.

Related free & paid tools

Tool nameTypeKey featuresLink
UptimeRobotOfferFreemiumMonitoring with public status pages and SLA reportsVisit
Better StackOfferFreemiumUptime monitoring, on-call and incident timelinesVisit
StatuspageOfferPaidCustomer-facing status and uptime communicationVisit
Google SRE WorkbookFreeHow to set error budgets behind an SLAVisit

Some links marked Offer are partner links. They cost you nothing extra and help keep these tools free.

Related tools

Frequently asked questions