SLA Uptime Calculator

Convert your uptime target into an allowed downtime budget, then compare it with your actual outages.

Fixed periods: 24-hour day, 7-day week, 30-day month, 91-day quarter and 365-day year. Calendar periods can differ.

Allowed downtime
0 d 00 h 43 m 12 s

Duration rounded to the nearest second. The budget calculation uses the unrounded value.

Add the downtime counted in the same period. For 30 seconds, enter 0.5 minutes. Enter 0 for no downtime.

Need to measure outages as they happen? Explore uptime monitoring for external checks, downtime history and alerts.

For a 30-day month, 99.9% uptime allows 43 minutes and 12 seconds of downtime. At 99.99%, the allowance falls to 4 minutes and 19.2 seconds, ten times less.

SLA uptime and downtime reference table

Allowed downtime for a 24-hour day, 7-day week, 30-day month, 91-day quarter and 365-day year. Durations are rounded; h and d values are approximate.
SLA Per day Per week Per month Per quarter Per year
99% 14m 24s 1.7h 7.2h 21.8h 3.6d
99.9% 1m 26s 10m 5s 43m 12s 2.2h 8.8h
99.95% 43s 5m 2s 21m 36s 1.1h 4.4h
99.99% 9s 1m 0s 4m 19s 13m 6s 52m 34s
99.999% 1s 6s 26s 1m 19s 5m 15s

SLA, SLO, SLI: What's the difference?

SLI (Service Level Indicator)

The raw measurement. The ratio of good events to total events over a time window (e.g. "99.95% of requests returned HTTP 200 in the last 30 days").

SLO (Service Level Objective)

Your internal target for an SLI. "We aim for 99.9% availability" is an SLO. Miss it and your team gets paged. It's a threshold you set for yourself.

SLA (Service Level Agreement)

An agreement with your customers that defines the service commitment and what happens if it is missed, such as service credits under specified conditions.

In practice: a tighter internal SLO can create a buffer before the public SLA target is missed. Choose both targets around the service users need and your ability to measure and operate it.

How to calculate allowed downtime from an SLA percentage

The formula is simple:

Allowed downtime = Total period × (1 - uptime target / 100)

Example: 99.9% uptime over 30 days:

43,200 min × (1 - 99.9 / 100) = 43.2 minutes

The calculator uses 43,200 minutes for a 30-day month and 525,600 minutes for a 365-day year. A calendar month can have 28, 29, 30 or 31 days; a leap year has 366. Substitute the actual period length when evaluating a calendar-based commitment.

Allowed downtime is a target-derived limit. Actual uptime is a measurement: (total period - counted downtime) / total period × 100. With 60 minutes of downtime in 30 days, actual uptime is 99.8611%, below a 99.9% target. That outage uses 138.9% of the 43.2-minute budget.

Use the same service scope and measurement rules throughout. This tool assumes time-based availability. It does not model request success rates, partial-service weighting or service credits. Planned maintenance counts according to your agreement, not an automatic exclusion in this calculator.

Common uptime targets: two to five nines

Monthly figures below use 30 days. Select a target based on the impact of an outage, recovery capability and customer commitments.

99% (two nines) - 7h 12m/month

A two-nines target allows 3 days, 15 hours and 36 minutes of downtime per 365-day year. Consider whether users can tolerate that interruption before choosing it for an internal tool or a non-critical workload.

99.9% (three nines) - 43m 12s/month

Three nines gives a 43.2-minute monthly budget. One hour-long outage uses more than the entire allowance, so recovery time and deployment reliability matter alongside redundancy.

99.95% (three-and-a-half nines) - 21m 36s/month

This target halves the downtime permitted at 99.9%. It can be useful when comparing service commitments without jumping straight to the much smaller four-nines budget.

99.99% (four nines) - 4m 19.2s/month

Four nines leaves 4.32 minutes per 30-day month. A single five-minute outage exceeds that allowance. Evaluate failover, dependency failures and deployment interruptions against this short recovery window.

99.999% (five nines) - 25.92s/month

Five nines leaves less than 26 seconds per 30-day month, or 5 minutes and 15.36 seconds per 365-day year. The measurement resolution and availability of every critical dependency become important at this scale.

Error budgets explained

An error budget flips the SLA question: instead of "how much uptime do we need?", it asks "how much downtime can we afford to spend?"

If your time-based SLO is 99.9% over 30 days, you have 43.2 minutes of budget. Every incident eats into it:

  • A 15-minute outage → 28.2 minutes left for the rest of the month
  • A risky deployment that goes wrong → costs 5 minutes of budget

When the budget is healthy: ship features, experiment, take calculated risks. When the budget is nearly spent: shift to reliability work. Fix flaky tests, improve rollback speed, add better monitoring.

Track both the remaining budget and how quickly it is being consumed when deciding whether to prioritize reliability work.

The key insight: some downtime is acceptable. A useful reliability target reflects the experience your users need. Error budgets help teams balance that target with the cost and risk of changes.

Why SLA monitoring matters

Knowing your SLA target is one thing. Knowing whether you're actually meeting it is another.

Without continuous monitoring, you're guessing at your actual availability. A 3-minute blip at 2 AM that nobody noticed still counts against your SLA, and those small incidents add up faster than most teams expect.

The worst scenario: finding out you've breached your SLA from a customer. Downtime history and timely alerts give the team a clearer starting point for investigating and restoring the service.

Effective SLA monitoring means:

  • Choosing a check interval and failure threshold short enough to detect outages relevant to your target
  • Matching the measurement window to the target: a rolling 30 days and a calendar month are different
  • Alerting your team when a service goes down or availability drops below a configured threshold
  • Recording which incidents and maintenance periods count under the agreed measurement rules

A monitoring check samples availability. Outages shorter than its interval can be missed, and detection also depends on retry and regional confirmation settings.

Fivenines supports HTTPS, TCP, ICMP and DNS checks, downtime history, and SLA threshold alerts over rolling 24-hour, 7-day or 30-day windows. See how uptime monitoring works.

FAQ

What does this SLA calculator measure? +
This free SLA calculator converts an uptime target into allowed downtime over a selected period. Choose one of the five targets from 99% to 99.999%, then optionally enter actual downtime to see the percentage of the budget used. It estimates a time-based budget; it does not measure your service or calculate service credits.
What does 99.9% uptime mean in practice? +
99.9% uptime allows 43 minutes and 12 seconds of downtime in a 30-day month, or 8 hours, 45 minutes and 36 seconds in a 365-day year. The allowance is 0.1% of the selected period.
What is the difference between 99.9% and 99.99% uptime? +
In a 30-day month, 99.9% allows 43 minutes and 12 seconds of downtime. At 99.99%, that falls to 4 minutes and 19.2 seconds: ten times less downtime. Each additional nine reduces the budget by a factor of ten.
How much downtime is allowed at 99.999% uptime? +
Five nines allows 25.92 seconds of downtime in a 30-day month and 5 minutes, 15.36 seconds in a 365-day year. The calculator rounds these durations to the nearest second.
Why do monthly SLA calculators show different results? +
The month length changes the answer. This calculator uses 30 days, so 99.9% gives 43.2 minutes. A 31-day month gives 44.64 minutes, while an average month derived from a year gives another value. For a calendar-month SLA, use the actual number of days and the agreement's measurement rules. A quarter here is 91 days and a year is 365 days.
How do I calculate my actual uptime percentage? +
Actual uptime = (total time - counted downtime) / total time × 100. For example, 60 minutes of downtime in a 30-day month gives (43,200 - 60) / 43,200 × 100 = 99.8611%. Use the same period and units for both values. This is measured availability, while an SLA target defines the availability you aim to meet.
What is an error budget? +
An error budget is the amount of unreliability an SLO allows. For a time-based 99.9% target over 30 days, it is 43.2 minutes. A 15-minute outage uses 34.7% of that budget and leaves 28.2 minutes. A request-based SLO instead measures failed requests, which this time-based calculator does not model.
What is the difference between SLA, SLO, and SLI? +
An SLI is the measured indicator, such as availability or request success rate. An SLO is a target for that indicator. An SLA is an agreement that defines the commitment and the consequences of missing it. A tighter internal SLO can provide a buffer before the SLA target is missed.
Does planned maintenance count as downtime? +
That depends on the agreement. Match its service scope, measurement period, definition of downtime and any maintenance exclusions. This calculator applies no exclusions automatically; enter only the downtime counted under the rules you are evaluating.
Can I monitor uptime against my target automatically? +
Fivenines runs HTTPS, TCP, ICMP and DNS checks and can alert when availability falls below a configured SLA threshold over a rolling 24-hour, 7-day or 30-day window. Choose the window and threshold that fit your monitoring objective; a rolling window is different from a calendar-month agreement.

Put your uptime target into practice with external checks, downtime history and alerts.

Start monitoring with fivenines.io

Not ready for a trial? Explore uptime monitoring first.