SLA Uptime Calculator

What Does SLA Uptime Mean?

A Service Level Agreement (SLA) uptime percentage expresses the fraction of time a system is expected to be operational and serving requests normally. When a vendor promises 99.9% uptime, they are committing that over any given measurement period — typically a calendar month or year — no more than 0.1% of that time will be spent in a degraded or unavailable state.

The difference between adjacent "nines" feels small on paper but is enormous in practice. The jump from 99% to 99.9% is 9× less downtime per year — roughly the difference between a weekend outage and a single overnight incident. The jump from 99.9% to 99.99% shaves another 9× off that, compressing your annual budget from under nine hours to under an hour. At five nines (99.999%), you are speaking in minutes per year — a level that requires fully redundant infrastructure, automated failover, and near-zero planned maintenance windows.

Availability percentages are almost always specified against total elapsed time, not just business hours, unless the SLA document explicitly carves out a "business hours only" scope. When reviewing a vendor contract, always check what time period the percentage is measured over and what events (planned maintenance, force majeure, dependency failures) are excluded from the downtime count.

The Nines Table

Industry convention describes availability levels by the number of "nines" in the percentage. Two nines (99%) is the baseline most operators consider insufficient for production services. Three nines (99.9%) is a common target for internal tools and low-criticality services — it allows about eight hours and 46 minutes of unplanned downtime per year. Four nines (99.99%) is frequently the minimum for customer-facing SaaS and public APIs, permitting just 52 minutes and 36 seconds per year. Five nines (99.999%) is the gold standard for carrier-grade telecommunications, financial trading systems, and emergency-services infrastructure — at just five minutes and fifteen seconds per year, this level requires sophisticated architecture, not just good operations.

The table shown above uses a 365-day year (31,536,000 seconds). Some SLA documents use a 30-day month (2,592,000 seconds) as the measurement window. Always verify which basis applies before calculating your incident budget, because the monthly allowance for 99.9% is only 43 minutes and 12 seconds — noticeably tighter than the annual figure suggests when amortized monthly.

MTTR and MTBF

Availability is not just a function of how often things break — it is equally a function of how quickly they are fixed. Two key metrics capture this relationship:

• Mean Time Between Failures (MTBF) — the average elapsed time between the end of one incident and the start of the next. A higher MTBF means failures are rarer.
• Mean Time To Repair (MTTR) — the average time from the moment a failure is detected to the moment service is fully restored. A lower MTTR means failures are shorter.

Availability can be expressed in terms of these two figures: Availability = MTBF / (MTBF + MTTR). A system that fails once every 30 days but takes four hours to repair has an availability of 720 / (720 + 4) = 99.45% — which sits between two and three nines. Improving MTTR through better observability, runbooks, and on-call processes can push you to three nines without changing the underlying failure rate at all. Conversely, a system with extremely rare failures but slow manual recovery can still miss a four-nine SLA.

For practical planning: to hit 99.99% with an MTTR of 30 minutes, your MTBF must be at least 3,000 hours — roughly one failure every four months. If your MTTR drops to five minutes, you only need an MTBF of 500 hours. Investing in automation and runbooks often has a better return on reliability than investing in hardware redundancy alone.

Planned vs Unplanned Downtime

Nearly every commercial SLA distinguishes between planned and unplanned downtime. Planned downtime — maintenance windows, scheduled upgrades, database migrations — is almost universally excluded from SLA calculations. The vendor notifies customers in advance, the work occurs during low-traffic hours, and the contractual clock is paused. Only unplanned, unexpected availability failures count against the SLA percentage.

This distinction matters enormously when comparing providers. A cloud vendor advertising 99.95% uptime that schedules four hours of maintenance per month is effectively providing less total availability than a competitor offering 99.9% with zero planned downtime. Always ask what the maintenance exclusion window looks like, and whether it compounds across regions or services.

For internal systems, the split is often reversed: organisations accept longer planned windows (Sunday 02:00–06:00 weekly) while setting strict incident response targets for unplanned outages. Tracking both separately in your incident management tool gives a cleaner picture of infrastructure reliability versus operational maturity.

SLA vs SLO vs SLI

Google's Site Reliability Engineering discipline popularised a three-layer model that cleanly separates what you measure, what you target, and what you promise:

• SLI (Service Level Indicator) — A specific, quantitative metric that measures one aspect of service behaviour. Examples: request success rate (successful responses / total requests), latency at the 99th percentile, data durability (objects not lost / total objects stored). An SLI is a raw number collected from telemetry.
• SLO (Service Level Objective) — An internal target for an SLI over a rolling window. "99.9% of HTTP requests will return a 2xx or 3xx status code over any 30-day window." SLOs are internal commitments — aspirational targets your team holds itself to. They should be tighter than your public SLA to give you an early-warning buffer.
• SLA (Service Level Agreement) — A contractual commitment to external customers, backed by penalties (service credits, refunds) if violated. SLAs should be set looser than SLOs, because the gap is your error budget: the room to absorb unexpected failures before a commitment is breached.

The practical implication: if your SLA is 99.9%, your SLO might be 99.95%, and your alerting fires when the rolling SLI drops below 99.97%. This three-tier structure prevents SLA violations from becoming existential surprises — by the time you breach an SLA, you have already been working the problem for days.

Worked Example — Calculating Your Incident Budget

Suppose you operate a SaaS platform with a published 99.9% annual uptime SLA. Your year contains 31,536,000 seconds. Your total allowed downtime is:

31,536,000 × (1 − 0.999) = 31,536 seconds ≈ 8 hours 45 minutes 36 seconds

That is your annual incident budget. Now suppose your post-mortems show that your average incident lasts 20 minutes from detection to resolution. How many incidents can you absorb before breaching the SLA?

31,536 seconds ÷ 1,200 seconds/incident ≈ 26 incidents per year

Twenty-six incidents — roughly two per month — exhausts your full annual SLA budget at 20-minute MTTR. If you want to hold 20% of that budget in reserve for longer incidents, you are looking at 20 incidents per year, or fewer than two per month. This framing makes the business consequences of reliability work concrete: every minute shaved off MTTR through better tooling or runbooks directly expands the number of incidents you can absorb without a contractual breach.

Related Calculators

• → TCP Throughput Calculator — Bandwidth-delay product and window sizing
• → Subnet Calculator — IPv4 network and host addressing

Disclaimer

This calculator provides reference figures for planning and education. Actual SLA definitions, measurement periods, exclusions, and penalty structures vary between vendors and contracts. Always refer to the specific language in your service agreement. This tool does not constitute legal or contractual advice.