How to Calculate Uptime SLA
A practical reliability guide for SaaS teams and agencies.
How to Calculate Uptime SLA from Sandglass: practical guidance for converting uptime percentages into concrete monthly downtime budgets and customer promises.
What this guide covers
This guide focuses on converting uptime percentages into concrete monthly downtime budgets and customer promises. The goal is to make the operating decision clear before a stressful incident forces the team to improvise.
- 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.
How Sandglass supports the practice
Pick the measurement window, exclude agreed maintenance periods only if the contract says so, and calculate downtime from customer-visible availability. Sandglass supports the continuous side of this work with checks, incidents, alert routing, and public status visibility.
- 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 promise availability your architecture and response process cannot support.
Implementation checklist
Step 1: Start from customer impact
Decide which failures in this topic actually reach customers before adding any monitoring.
Step 2: Choose one signal per risk
Match each risk to a single HTTP, content, TCP, SSL certificate, or heartbeat check instead of stacking duplicates.
Step 3: Assign an owner and a channel
Give each alert one owner and one destination — email, a Slack webhook, or a generic webhook.
Step 4: Review after real incidents
Revisit intervals, thresholds, and ownership once a real incident shows what was missing.