Service availability (uptime): formula and the “nines”
Uptime / Availability is the share of time a service operates within agreed quality targets (SLO): request success rate, latency, errors. It is a baseline SLI for products and platforms that directly affects SLA compliance, user experience, and revenue.
What the Metric Measures
The share of "healthy" service time according to the selected criterion: successful responses (2xx/3xx), errors (5xx), latency (≤ target), percentage of valid events. Separately measure critical dependencies (database, cache, payment gateway, CDN) and regions/availability zones.
Calculation
- Uptime, % = (Total time − Downtime) / Total time × 100
- Downtime, min = Σ Incidents (actual unavailability interval)
- Availability SLI = Successful requests / All requests × 100 (filtered by SLO latency)
- SLO — availability target (e.g., 99.9% over 30 days)
- Error Budget = 100% − SLO; Burn Rate = Budget consumed / Time
- MTTR = Mean time to recovery; MTBF = Mean time between failures
Fix the rules: measurement window (e.g., rolling 30 days), business vs. calendar time, planned windows (maintenance), partial outages (weighted by traffic/users), time zones.
Calculation example
A 30-day month has 43,200 minutes, and the service was down for 54 minutes. Availability = (43,200 − 54) / 43,200 × 100 = 99.875%. A 99.9% SLA allows only 43 minutes of downtime a month, so the commitment was missed.
Data Sources
Monitoring/APM (requests, errors, latency), synthetic checks (HTTP/DNS/SSL), RUM/client telemetry, infrastructure alerts (VM/K8s/DB/queue), incident/on-call logs, status page.
Interpretation
- Uptime↓ or a high burn rate — risk of missing the SLO/SLA; stabilization changes and a change freeze are needed
- MTTR↑ — weak alerting/diagnostics/escalations; MTBF↓ — technical debt, "hot deploys"
- Regional/partial outages are masked by the average — weight by real traffic
Useful Breakdowns
- Service/endpoint; criticality (P0–P3); environment (prod/stage)
- Region/zone; ISP/CDN; client type (web/iOS/Android/API)
- Incident type (infrastructure/deploy/dependency/DDoS/config)
- Latency P50/P95/P99; share of 5xx/4xx; resource saturation
Dashboard Visualizations
- Uptime% and SLO compliance trend over 7/30 days
- Error Budget burn-down and instantaneous burn rate (1 h / 6 h)
- Incident timeline with causes/deploy annotations
- Availability heatmap by region/endpoint
- Correlations of Uptime ↔ conversion/revenue/CSAT
How to Set Targets
Define SLOs by criticality (e.g., core — 99.95–99.99%, auxiliary — 99.5–99.9%), error budget rules, and downweights for regions/endpoints. Set up clear SLAs for customers, P0/P1 escalations, auto-rollback, canary releases, and postmortem practices with actions (CAPA).
Common Mistakes
- Counting "ping is alive" as business function availability; ignoring latency
- Not accounting for partial/regional outages or dependencies (database, payments, CDN)
- Mixing planned work with downtime without a maintenance policy
- No rolling 30-day window and no error budget control
- Lack of clear alerts/runbooks/escalations
Questions for Discussion
- Which dependencies "break" availability most often, and how can they be isolated?
- Are our error budgets and change management policy sufficient?
- Where can we reduce MTTR: notifications, observability, runbook scripts?
- What is the impact of canary/blue-green releases on Uptime and risks?