How to Calculate Uptime SLA (With a Downtime Table)

What this guide covers

An SLA (Service Level Agreement) turns "we are reliable" into a number you are contractually on the hook for. This guide shows how uptime percentage is calculated, translates the common targets into real allowed downtime, and explains how to choose a measurement window and a target you can actually defend when a customer holds you to it.

• Define the measurement window before quoting a number.
• Measure from customer-visible availability, not internal metrics.
• An SLA you cannot defend is worse than a lower, honest one.

The uptime formula

Uptime percentage is simply: (total time − downtime) ÷ total time × 100, measured over an agreed window (usually a calendar month). If a service was down for 20 minutes in a 30-day month (43,200 minutes), uptime is (43,200 − 20) ÷ 43,200 × 100 = 99.95%. The window matters: the same 20-minute outage is 99.95% monthly but 99.996% annually, so always state the window alongside the number.

Downtime allowed per uptime target

This is what each "nines" target actually permits. Use it to sanity-check any SLA you are asked to sign, or work it out for your own target with the uptime SLA calculator.

• 99% — about 7.2 hours of downtime per month (3.65 days/year).
• 99.9% ("three nines") — about 43 minutes per month (8.76 hours/year).
• 99.95% — about 22 minutes per month (4.38 hours/year).
• 99.99% ("four nines") — about 4.3 minutes per month (52.6 minutes/year).
• 99.999% ("five nines") — about 26 seconds per month (5.26 minutes/year).

Choosing a target you can defend

Work backwards from your operations, not from what sounds good. Ask: how fast do we detect an outage, how fast do we respond, and what dependencies do we not control? A single unmanaged third-party dependency with its own 99.9% SLA effectively caps yours at 99.9% or lower. Promising more than your weakest link supports means paying out credits on incidents you could never have prevented.

How Sandglass supports the practice

Measure availability the way your customers experience it — external checks against customer-facing endpoints — and use that as the basis for your SLA reporting. Sandglass records uptime from your checks so the percentage you report is grounded in measured, customer-visible availability rather than internal server metrics that hide user-facing failures.

• Back the practices here with HTTP, ping, TCP, content, SSL certificate, and heartbeat checks.
• Route incidents to email, Slack webhook channels, and generic webhooks so the right people respond fast.
• Use a public status page to keep customers informed while the team works the incident.

Common mistakes to avoid

An SLA number is a commercial promise, not just a dashboard metric. Do not quote 99.99% because it sounds impressive if your architecture, dependencies, and response process only support 99.9%. Also decide upfront whether planned maintenance is excluded — and only exclude it if the contract explicitly says so.