SLA Downtime and Error Budget Calculator

Table of Contents

• The formula
• Choose the measurement window
• SLA, SLO, and SLI
• Worked annual and monthly example
• How an incident consumes the budget
• Decide how to treat planned maintenance
• Partial degradation and request success
• Use self-hosted monitors
• Common interpretation mistakes
• Next steps
• FAQ

The formula

The downtime budget is the portion of a measurement window your service may be unavailable while meeting its target:

Error budget fraction = 1 - availability target
Allowed downtime = measurement-window length × error budget fraction

For a 99.9% target, the decimal target is 0.999, so the error budget fraction is 1 - 0.999 = 0.001: one tenth of one percent of the selected window is available for unavailability.

The calculator translates that fraction into minutes, hours, and seconds. It does not decide what counts as unavailable; your monitoring rule does, such as a failed health check, failed user request, or sustained response-time threshold.

Availability is a ratio, not a promise about every request. High time-based availability can coexist with errors for many users. Treat the result as an error-budget planning number and pair it with a useful service-level indicator.

Choose the measurement window

The same percentage produces different budgets in different windows. Always write the window beside the target: “99.9% over a calendar year” and “99.9% over a rolling 30 days” are different commitments.

For a yearly budget, decide whether you use a 365-day year, a calendar year with actual length, or another fixed period. The default uses 365 days, or 525,600 minutes. The calculator’s average month is 30.4375 days, or 43,830 minutes.

A fixed window is easy to audit. A rolling window suits an always-on self-hosted service because yesterday’s incident gradually leaves the calculation instead of resetting. Document and apply consistently.

The monitoring definition must match the window. One-minute checks can look precise but measure the wrong experience when the target represents user requests. Define the source, frequency, locations, and missing-data handling.

SLA, SLO, and SLI

An SLI measures successful HTTP requests, successful probes, or a latency percentile at a defined endpoint. An SLO is its target, such as 99.9% successful requests over a stated window. An SLA is broader and may include obligations, exclusions, credits, and terms.

This calculator is for SLO-style availability and error-budget math. It is not legal SLA advice or a vendor promise. If a hosted provider publishes an SLA, use its definitions and terms rather than assuming this percentage matches the contract.

For self-hosting, choose an SLO reflecting user needs and an observable, reproducible SLI.

Worked annual and monthly example

At 99.9% availability, the error budget fraction is 0.001. In a 365-day year:

525,600 minutes × 0.001 = 525.6 minutes

That equals 8 hours, 45 minutes, and 36 seconds of allowed unavailability.

Using the calculator’s average 30.4375-day month:

43,830 minutes × 0.001 = 43.83 minutes

That equals 43 minutes and 49.8 seconds. Both are correct: one covers the 365-day window, and the other covers one average month.

Window	Minutes in window	99.9% allowed downtime
365-day year	525,600	525.6 minutes (8:45:36)
Average month	43,830	43.83 minutes (43:49.8)

Do not add a monthly budget to an annual budget or compare a calendar month with the average month without noting the difference. A 28-day month and a 31-day month have different absolute budgets.

How an incident consumes the budget

An incident uses a share of the budget equal to its duration divided by allowed downtime for the same window:

Budget consumed = incident duration ÷ allowed downtime × 100

A 120-minute incident consumes 120 ÷ 525.6 × 100 = 22.83% of the annual 99.9% budget. Against the average monthly budget, it consumes 120 ÷ 43.83 × 100 = 273.79%.

The second result does not mean the incident was 273.79% unavailable; it means more than twice the average monthly budget. Inside a monthly window, it cannot meet 99.9% based on time alone; the annual window may still have budget remaining.

Track duration and impact: a ten-minute outage affecting every user and a ten-minute failure affecting one endpoint are not equivalent, even with the same monitor duration. Record times, signal, and budget window.

Decide how to treat planned maintenance

Planned maintenance counts when the objective represents the service users can reach throughout the window. Excluding it can make the number look healthier while hiding an interruption.

You might include maintenance in a user-facing objective while tracking a separate objective for unplanned outages. Write the policy down before the next event and apply consistently.

A clear policy should say whether scheduled shutdowns count, whether a maintenance page is available, and whether an approved change pauses measurement. Keep the raw event in monitoring history even when reporting excludes it.

Partial degradation and request success

Time-based availability cannot fully represent partial failures or request-level error rates. A server may answer health checks while a database-backed action fails, or work for most users while failing in one region or endpoint. One minute can contain more failed requests than another.

Use a request-based SLI to protect user success. It can be successful requests divided by total valid requests, with rules for retries, redirects, client errors, and excluded traffic. For a multi-component service, consider critical-path indicators.

Keep time-based monitoring as a fast signal. Add request success, latency, and dependency checks where they reveal different failure modes. Measure the experience your target describes.

Use self-hosted monitors

A self-hosted monitor is most useful when it measures the service where users are. Tools such as Uptime Kuma and Gatus can record probe results, response times, and incident intervals. Choose a meaningful endpoint without unnecessary load.

See OpenAlt’s monitoring category for guidance. If the service is private, run the monitor where it can observe the failure you care about. An internal probe confirms LAN availability; it cannot prove a remote user can connect through DNS, a reverse proxy, authentication, and the public network.

Document interval, timeout, retries, probe location, maintenance handling, and alert threshold. A missed check may be noise; repeated failures may define an incident. These choices affect duration in the budget.

Common interpretation mistakes

• Treating 99.9% as a universal promise. It has no meaning without a window and measurement definition.
• Reporting only the percentage. A duration such as 525.6 minutes is easier to schedule against.
• Mixing windows. Compare an incident with the budget for the window that contains it.
• Assuming monthly budgets add up cleanly. Calendar months differ in length, and rolling windows overlap.
• Ignoring blind spots. A green probe from one network does not prove every user path is healthy.
• Treating planned maintenance as automatically excluded. The policy must be explicit.
• Using uptime as the only signal. Partial failures, slow responses, and request errors can be invisible.
• Calling the result an SLA. This page calculates a budget; it does not establish contractual terms.

Next steps

Start with one user-visible service. Write an objective covering target, window, SLI, probe location, and maintenance policy. Configure a monitor and record a baseline before changing the target.

Use self-hosted resources to choose an approach. After each incident, review consumed budget, affected users, and whether the SLI measured the failure. If the budget disappears quickly, improve reliability or lower the target; do not redefine the measurement afterward.

FAQ

How much downtime does 99.9% permit?

It depends on the window. In a 365-day year, 99.9% permits 525.6 minutes, or 8 hours, 45 minutes, and 36 seconds. In the average 30.4375-day month, it permits 43.83 minutes, or 43 minutes and 49.8 seconds.

Why do monthly and annual budgets differ?

The percentage is applied to the minutes in each window. A year contains more minutes than an average month, so its absolute budget is larger.

Does planned maintenance count?

It counts when the objective represents the service users can reach throughout the window. You may measure scheduled work separately, but state whether it is included or excluded. Keep the event in raw records either way.

Is uptime alone enough?

No. Uptime can miss partial failures, slow responses, regional problems, and request errors. Pair it with an SLI for successful user requests or another critical outcome.