Stage 5 · Platform
SRE Patterns on Azure
SLOs on Azure
Azure platform SLAs vs your service SLOs, error budget burn rate, and dashboards.
SLOs Overview
A Service Level Objective (SLO) is a target for the reliability of a service. It defines what percentage of time the service must be available and perform correctly. SLOs are measured over a rolling window (typically 30 days).
// SLO calculation: (total - errors) / total * 100
let slo_target = 99.9;
let window = 30d;
requests
| where timestamp > ago(window)
| summarize
Total = count(),
Errors = countif(success == false)
| extend Availability = round((todouble(Total - Errors) / todouble(Total)) * 100, 3)
| extend SLOTarget = slo_target
| extend SLOMet = iff(Availability >= slo_target, "Met", "Breached")The SLO is calculated over a 30-day rolling window. 99.9% availability allows 43.2 minutes of downtime per month.
Azure Platform SLAs
Azure publishes SLAs for every service. Your service SLA is the product of all component SLAs. If your service depends on VMs (99.95%) and Storage (99.9%), your composite SLA is 99.95% * 99.9% = 99.85%.
| Service | SLA | Downtime/Month |
|---|---|---|
| Azure VMs (single instance) | 99.9% | 43.8 min |
| VMs in Availability Set | 99.95% | 21.9 min |
| VMs in Availability Zone | 99.99% | 4.38 min |
| AKS (control plane) | 99.95% | 21.9 min |
| Azure Blob Storage (GRS) | 99.99% | 4.38 min |
| Azure SQL (Business Critical) | 99.995% | 2.16 min |
| Azure Front Door | 99.99% | 4.38 min |
Your service SLA is always lower than the lowest individual SLA. To achieve 99.99% for your service, every component must be above 99.99% or you need redundancy.
Defining Your SLOs
- Availability SLO — Percentage of successful requests (200-299 status codes)
- Latency SLO — Percentage of requests under a latency threshold (e.g., p99 < 500ms)
- Freshness SLO — For data pipelines, percentage of data delivered within SLA
- Correctness SLO — Percentage of requests that return the correct result
- Durability SLO — Percentage of data retained without loss over time
// Latency SLO: 99% of requests under 500ms
requests
| where timestamp > ago(30d)
| summarize
Total = count(),
UnderThreshold = countif(duration < 500ms),
P50 = percentile(duration, 50),
P99 = percentile(duration, 99)
| extend LatencySLO = round(todouble(UnderThreshold) / todouble(Total) * 100, 2)Latency SLOs use percentiles, not averages. p99 is the latency that 99% of requests are faster than. It catches tail latency issues that averages miss.
Error Budget
// Error budget for 99.9% SLO over 30 days
let slo_target = 99.9;
let error_budget_pct = 100 - slo_target; // 0.1%
let window = 30d;
let total_requests = requests
| where timestamp > ago(window)
| summarize Total = count();
let error_requests = requests
| where timestamp > ago(window)
| where success == false
| summarize Errors = count();
total_requests
| extend
ErrorRate = round(todouble(Errors) / todouble(Total) * 100, 4),
BudgetUsed = round(todouble(Errors) / todouble(Total) * 100 / error_budget_pct * 100, 1),
BudgetRemaining = round(error_budget_pct - (todouble(Errors) / todouble(Total) * 100), 4),
TimeRemaining = datetime_diff('minute', datetime(30d), ago(window))The error budget is 0.1% of total requests (for a 99.9% SLO). If you have used 50% of the budget, you can only fail for half the remaining time.
Burn Rate
Burn rate measures how fast you are consuming your error budget. A burn rate of 1.0 means you are consuming at the sustainable rate. Above 1.0 means you will exhaust the budget before the window ends.
// Alert if burn rate > 2x for 1 hour (will exhaust budget in 15 days)
let slo_target = 99.9;
let error_budget = 100 - slo_target;
let burn_rate_threshold = 2;
requests
| where timestamp > ago(1h)
| summarize
Total = count(),
Errors = countif(success == false)
| extend
ErrorRate = todouble(Errors) / todouble(Total) * 100,
BurnRate = (todouble(Errors) / todouble(Total) * 100) / error_budget
| where BurnRate > burn_rate_thresholdBurn rate alerts are more reliable than simple error count alerts. They account for traffic volume and SLO target, reducing false positives.
Google SRE recommends using two burn rate windows (1h and 6h) to catch both fast burns and slow burns. The 1h window catches acute incidents; the 6h window catches gradual degradation.
SLO Dashboards
# Create a workbook for SLO tracking
az monitor app-insights workbook create \
--resource-group rg-monitoring \
--display-name "SLO Dashboard" \
--category workbooks \
--location eastus \
--kind shared \
--serialized-data @workbook-slo.jsonSLO dashboards should show current availability, error budget remaining, burn rate, and trend over time. Share them with engineering and leadership.
When error budget is healthy, teams can ship faster. When budget is low, teams must focus on reliability. SLOs create a shared framework for risk tolerance between product and engineering.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.