Uptime SLA Calculator

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.