Uptime SLA Calculator
A practical reference for teams that need to translate an uptime percentage into a downtime budget.
Free uptime SLA calculator: convert an uptime percentage into allowed monthly and yearly downtime, and see what a tighter SLA really demands of your operations.
Work out your allowed downtime
Anything from 0 up to — but not including — 100.
| Period | Allowed downtime |
|---|---|
| Per day | 1m 26s |
| Per week | 10m 5s |
| Per month | 43m 12s |
| Per year | 8h 45m 36s |
| Uptime target | Per month | Per year |
|---|---|---|
| 99% | 7h 12m | 3d 15h 36m |
| 99.5% | 3h 36m | 1d 19h 48m |
| 99.9% | 43m 12s | 8h 45m 36s |
| 99.95% | 21m 36s | 4h 22m 48s |
| 99.99% | 4m 19s | 52m 34s |
| 99.999% | 26s | 5m 15s |
When to reach for this tool
Reach for this when you need to translate an uptime percentage into a downtime budget during setup, debugging, or an incident review. A one-off check is useful for diagnosis, but production systems need continuous monitoring once the immediate question is answered.
- 99.9% leaves tens of minutes per month; 99.99% leaves a few.
- A tighter SLA demands faster detection and a real escalation path.
- Scheduled maintenance and dependency risk eat into the budget too.
Downtime allowed per uptime target
This is what each "nines" target actually permits over a month and a year. Use it to sanity-check any SLA before you commit to it — the gap between adjacent tiers is roughly 10x, not a rounding error.
- 99% — about 7.2 hours per month (3.65 days per year).
- 99.9% ("three nines") — about 43 minutes per month (8.76 hours per year).
- 99.95% — about 22 minutes per month (4.38 hours per year).
- 99.99% ("four nines") — about 4.3 minutes per month (52.6 minutes per year).
- 99.999% ("five nines") — about 26 seconds per month (5.26 minutes per year).
From one-off check to continuous monitor
Use the downtime budget to choose how fast you need to detect failures, who owns escalation, and how much redundancy your promise actually requires.
- Recreate the same check in Sandglass on an interval so the next change is caught without re-running the lookup.
- Send failures to email, a Slack webhook channel, or a generic webhook owned by whoever fixes the problem.
- Track the result over time instead of treating one manual reading as the final answer.
Why a lookup is not monitoring
An SLA is a commercial commitment, not a dashboard metric. Do not promise a number your detection speed and response process cannot defend during a real incident.
Use this tool well
Step 1: Run the check and read the result
Use the output to confirm the current state, and treat anything surprising as a starting point for diagnosis rather than a verdict.
Step 2: Define what healthy means
Write down which results count as healthy, degraded, or failed before you automate anything.
Step 3: Promote it to a continuous monitor
Recreate the same check in Sandglass on an interval so the next change is caught automatically.
Step 4: Route the alert to an owner
Send failures to email, a Slack webhook channel, or a generic webhook owned by whoever will fix them.