Uptime and SLA Calculator

Service level agreements (SLAs) and internal reliability targets are usually written as a percentage of uptime, such as 99.9%. This calculator turns any uptime target into the downtime it allows per year, quarter, month, week and day; works out the uptime achieved from measured outage minutes; and combines the availability of several components that depend on each other or back each other up. A chart shows how each additional nine shrinks the allowed downtime.

allowed downtime = (1 − uptime) × length of the period

series (all required): A = A₁ × A₂ × …

parallel (any one is enough): A = 1 − (1 − A₁) × (1 − A₂) × …

The calculator uses a 365-day year and a 30-day month, the convention in most published SLA tables, including the availability table in Google's Site Reliability Engineering book. Contracts may define the period differently, for example by calendar month, so check the wording of your SLA.

A web request that passes through a load balancer at 99.95%, an application at 99.9% and a database at 99.99% succeeds only if all three are up, so the end-to-end availability is 99.840%, lower than any single part. Redundancy works the other way: two independent servers that are each up 99% of the time give 99.99% availability when either one can serve traffic. The parallel formula assumes failures are independent; in practice shared power, networks, regions or software bugs make redundant components fail together more often, so real gains are smaller.

Site reliability engineering teams treat the allowed downtime as an error budget. With a 99.9% target, the 43 minutes a month that may be lost can be spent on risky deployments and experiments; when the budget runs out, teams slow releases and focus on reliability. This turns the trade-off between shipping features and stability into a number that both product and operations teams can plan around.

Higher targets cost more. Moving from three nines to four nines usually means redundant infrastructure across zones, automated failover, careful change management and on-call engineers who can respond within minutes. Many internal tools work well at 99.5%, while payment systems and core infrastructure often aim for 99.99% or more. A useful rule is to set the target slightly above what your users actually notice and no higher than the services you depend on can support, since a service cannot be more available than its dependencies in series.

Cloud and hosting providers usually back their SLAs with service credits rather than refunds: if monthly uptime falls below the promised level, you receive a percentage of that month's bill back, often only after filing a claim. The credit is typically far smaller than the business cost of the outage, so design your own redundancy rather than relying on credits. Read the definitions of downtime, exclusions and claim deadlines in your provider's agreement.

• Define what counts as down: a full outage only, or also slow or partial failures above an error-rate threshold.
• Decide whether planned maintenance counts. Many SLAs exclude announced maintenance windows.
• Measure from where users are, such as external checks, rather than only from inside your network.
• Request-based availability (successful requests ÷ total requests) is often fairer than time-based uptime for busy services.