What Does 99.9% Uptime Really Mean? A Practical Guide to SLAs and Downtime Budgets

An uptime claim such as 99.9% sounds nearly perfect. Over a 30-day month, however, it permits 43 minutes and 12 seconds of downtime. Whether that is acceptable depends on what failed, when it failed, how many users were affected, and how the percentage was measured.

The percentage alone is not a reliability policy. A useful target must define the service, successful behavior, measurement source, time window, exclusions, and consequences of missing it.

This guide explains the downtime math and the decisions behind a credible availability target.

How uptime is calculated​

The simplest time-based formula is:

availability = (measurement time - downtime) / measurement time x 100

If a service was unavailable for 43.2 minutes during a 43,200-minute month:

(43,200 - 43.2) / 43,200 x 100 = 99.9%

This calculation looks objective, but every term needs a definition. When did downtime begin? Did it end after one successful check or after stable recovery? Does planned maintenance count? Is the entire product down when one region fails?

Without those rules, two teams can report different availability for the same incident.

How much downtime do the nines allow?​

The following table assumes a 24-hour service, a 30-day month, and a 365-day year. Values are rounded for readability.

Availability	Downtime per day	Downtime per 30-day month	Downtime per year
99%	14m 24s	7h 12m	3d 15h 36m
99.9%	1m 26s	43m 12s	8h 45m 36s
99.95%	43s	21m 36s	4h 22m 48s
99.99%	9s	4m 19s	52m 34s
99.999%	Less than 1s	26s	5m 15s

Google SRE publishes a similar availability table and notes that operation-based measurements are often more useful when a service is partially available or traffic changes throughout the day.

An extra nine is expensive. Moving from 99.9% to 99.99% reduces the monthly budget from more than 43 minutes to just over 4 minutes. That difference affects architecture, staffing, deployment safety, recovery automation, and monitoring speed.

The measurement window changes the result​

A service can meet 99.9% annually while missing it badly in one month.

For example, a single three-hour outage produces about 99.59% availability in a 30-day month. If the other eleven months are perfect, annual availability is still about 99.966%.

Neither figure is mathematically wrong. They answer different questions.

Common windows include:

• Calendar month for customer contracts and service credits.
• Rolling 28 or 30 days for operational dashboards.
• Quarter for services with very small error budgets.
• Year for high-level reporting.

Define the timezone, window boundaries, and reporting delay. A monthly SLA should not silently become an annual average when a bad month occurs.

Time-based versus request-based availability​

Time-based availability asks what portion of the window the service was usable. It works well for a website or endpoint observed at regular intervals.

Request-based availability asks what portion of eligible operations succeeded:

availability = successful eligible requests / all eligible requests x 100

Request-based measurement better represents services with uneven traffic. Five minutes of failure during peak traffic may harm more customers than thirty minutes at a quiet time. It also handles partial outages more naturally.

Both approaches have limits:

• Time-based monitoring samples the service and can miss failures between checks.
• Request metrics may exclude users who could not reach the system at all.
• Server-side success may not mean the client received the right result.
• A fast error should not count as a successful request.
• Synthetic traffic may not match the real distribution of users and operations.

A mature service often uses request data as the primary availability indicator and external synthetic checks as independent evidence that DNS, routing, the edge, and critical workflows work from outside the application.

SLI, SLO, and SLA are different​

These terms are related but not interchangeable.

Service level indicator (SLI)​

An SLI is the measurement. Examples include successful checkout requests divided by eligible checkout requests, or the percentage of login attempts completed within two seconds.

Service level objective (SLO)​

An SLO is the target for an SLI. For example: 99.9% of eligible checkout requests succeed over a rolling 30-day window.

Service level agreement (SLA)​

An SLA is an agreement with users or customers that includes consequences when its commitments are missed. Those consequences may include service credits, refunds, or other remedies.

Google's service level objectives chapter offers a useful test: if missing the target has no explicit contractual consequence, it is probably an SLO rather than an SLA.

Teams usually set an internal SLO stricter than the external SLA. That safety margin creates time to respond before a customer commitment is breached.

What is an error budget?​

An error budget is the allowed failure portion of an SLO:

error budget = 100% - SLO

A 99.9% availability SLO provides a 0.1% error budget. Over one million eligible requests, that is 1,000 failed requests. Over a 30-day time-based window, it is 43.2 minutes of downtime.

The budget turns reliability into an operating decision:

• If the service is comfortably within budget, the team can accept normal release risk.
• If budget consumption is accelerating, the team can slow changes and investigate.
• If the budget is exhausted, reliability work may take priority over feature delivery.

Do not treat an error budget as scheduled outage time. It is a limit on unavoidable failure and managed risk, not permission to spend downtime carelessly.

Google SRE describes error budgets as a way to balance service reliability with the pace of change.

Planned maintenance must be defined​

Some SLAs exclude planned maintenance. Others count every minute the customer-facing service is unavailable.

If maintenance is excluded, define:

• Required advance notice.
• Maximum duration and frequency.
• Approved maintenance windows.
• Whether emergency maintenance qualifies.
• Whether degraded access counts as unavailable.
• How overruns are measured.

Excluding maintenance from a contract does not remove its customer impact. Track total user-visible availability separately so operational reporting does not look healthier simply because downtime was announced.

Maintenance windows should suppress expected alerts and status noise, but they should not erase monitor data. Preserve the evidence needed to confirm that the service recovered on time.

Partial outages need more than a binary check​

A service can be partly broken while its homepage remains up:

• One geographic region cannot connect.
• Login works, but checkout fails.
• Read requests succeed while writes fail.
• One tenant or account type is affected.
• The API returns 200 OK with incorrect data.
• Requests succeed but exceed the promised latency.

Calling the entire service either up or down loses important information.

For request-based SLIs, count affected operations. For regional or component-based services, define separate indicators and objectives. A critical workflow can also have its own SLI, such as the fraction of synthetic checkout runs that complete successfully.

Avoid averaging away severe impact. If a small region has few requests but a contractual commitment, its availability may need to be evaluated separately. Our multi-region monitoring guide covers regional alert and recovery policies in more detail.

A high uptime percentage can hide a broken workflow​

Suppose the public website receives one million successful page requests in a month, but all 2,000 checkout attempts fail for an hour. A broad request count might still show roughly 99.8% success. For the revenue-producing workflow, availability was 0% during the incident.

Measure outcomes users care about:

• Can a customer sign in?
• Can an order be submitted?
• Can an API client retrieve correct data?
• Can a scheduled job complete before its deadline?
• Can users in each required region reach the service?

Basic HTTP uptime remains valuable, but it should be paired with content assertions and a small number of critical browser or API workflows. See our website monitoring checklist for a layered approach.

Monitoring precision must match the target​

A monitor checking every five minutes cannot precisely prove a monthly 99.99% target that allows only about four minutes of downtime. Confirmation checks and consecutive-failure thresholds can add more detection delay.

Define how sampled checks map to incident time:

• Does downtime begin at the last success, first failure, or midpoint between them?
• Does an immediate retry replace the original result?
• How many failures open an incident?
• How many successes confirm recovery?
• How are missing checks classified?
• Which regions must fail?

Extremely high objectives can be smaller than the monitoring and response loop. Google SRE notes that a total outage can exhaust a monthly 99.999% budget in about 26 seconds, which may be shorter than collection and alert delivery time. Their SLO alerting guidance recommends alerting on meaningful threats to the budget rather than waiting until it is gone.

Use frequent external checks for fast detection, request telemetry for accurate accounting, and burn-rate alerts for sustained budget risk.

Define an availability policy that can be audited​

A credible SLO or SLA should answer:

• What service or user journey is covered?
• What exactly counts as success?
• Which requests, users, regions, and errors are eligible?
• Is availability time-based, request-based, or both?
• What is the measurement source?
• What is the reporting window and timezone?
• How are partial failures weighted?
• Does slow service count as unavailable?
• How are planned maintenance and customer-caused errors handled?
• When does an incident start and end?
• What happens when the target is missed?

Write these rules before an incident. Changing exclusions after a miss undermines both the metric and customer trust.

Common uptime reporting mistakes​

• Reporting only the best measurement: Internal metrics can stay green when users cannot reach the service.
• Using the homepage as the whole product: A successful page request does not prove login, APIs, or checkout work.
• Averaging all regions together: A smaller market can disappear inside a global percentage.
• Excluding all maintenance: Announced downtime still affects users and should remain visible operationally.
• Ignoring latency and correctness: An unusably slow or incorrect response is not meaningfully available.
• Setting more nines without a plan: Architecture and response capability must support the target.
• Treating the SLA as the internal goal: Operating at the contractual boundary leaves no safety margin.

Start with a target users can recognize​

99.9% uptime is not inherently good or bad. It is a budget of failure attached to a specific service and measurement window.

Choose an SLI that represents a real user outcome. Set an SLO that balances customer expectations with realistic engineering cost. Keep the internal target stricter than any contractual SLA, and use the remaining error budget to guide release and reliability decisions.

Testable Monitoring supports HTTP, ping, port, heartbeat, and scripted workflow monitors, with incident history, regional results, metrics, maintenance windows, notifications, and monitor-backed status pages. External checks can complement application request data and provide evidence of what users can reach from outside your infrastructure.

For related guidance, read what synthetic monitoring can prove and how to choose check frequency and alert thresholds.