CDN SLOs, SLIs, and Error Budgets: Reliability Engineering for Content Delivery

Reliability engineering for CDN infrastructure requires more than uptime dashboards and alerting thresholds. Service Level Objectives (SLOs) establish what “reliable enough” means in concrete, measurable terms. Service Level Indicators (SLIs) provide the measurements. Error budgets translate the gap between perfection and the SLO target into actionable decision-making currency. Together, these three concepts transform CDN reliability from a vague aspiration into an engineering discipline that balances innovation velocity with user experience — a fundamental challenge in CDN architecture at scale.

Understanding the SLI/SLO/SLA Hierarchy

The terminology originates from Google’s Site Reliability Engineering practice and forms a layered system. At the bottom sits the SLI: a quantitative measure of some aspect of service behavior. An SLI answers “what are we measuring?” For CDN, the most common SLIs are availability (the proportion of successful requests), latency (the time from request receipt to response delivery), and throughput (requests per second or bytes per second served without error).

The SLO sits above the SLI and sets a target value over a specific time window. An SLO answers “how good should the measurement be?” Rather than aspirational statements like “the CDN should be fast,” an SLO makes a precise commitment: “99.95% of edge requests return HTTP 200 within a 30-day rolling window.” This precision enables objective evaluation of whether the service is meeting its reliability targets.

The SLA (Service Level Agreement) is the contractual layer, typically between the CDN provider and its customers. SLAs define consequences — usually financial credits — when SLOs are breached. Internal teams should set their SLOs tighter than their SLAs, creating a buffer that triggers engineering action before contractual obligations are violated.

Choosing the Right SLIs for CDN Infrastructure

Not every metric makes a good SLI. Effective SLIs share three properties: they directly correlate with user experience, they are measurable with low overhead, and they are actionable (an engineering team can improve them). For CDN infrastructure, four categories of SLIs capture the dimensions that users care about most.

Availability SLI

Availability measures the proportion of valid requests that receive a successful response. The standard formula divides successful requests by total valid requests over the measurement window. “Successful” means an HTTP status code in the 2xx or 3xx range (or a cached 304 response). “Valid” excludes requests that are inherently invalid (malformed URLs, blocked by WAF rules) because counting security blocks as failures would penalize security enforcement.

Availability SLI = (count of 2xx/3xx responses)
                   ÷ (total valid requests)
                   × 100%

Example (30-day window):
  Total valid requests:  847,293,412
  Successful responses:  846,869,100
  Failed responses:          424,312
  Availability SLI:          99.9499%

The measurement point matters. Availability measured at the edge node captures CDN-layer failures but misses issues between the edge and the client (last-mile problems). Availability measured via synthetic probes from real client locations captures end-to-end reliability but depends on probe coverage. A robust approach uses both: edge-side availability as the primary SLI, supplemented by synthetic probe availability as a validation signal.

Latency SLIs

CDN latency SLIs use percentile measurements rather than averages. Averages are dangerous because they hide bimodal distributions — a system where 99% of requests take 10ms and 1% take 5 seconds has a “good” average of 60ms but a terrible tail-latency experience. Percentile SLIs capture the distribution shape that users actually experience.

Standard CDN latency SLIs target three percentiles measured at the edge:

Latency SLI targets (edge-served, cache HIT):
  p50 (median):  ≤ 30ms     — typical user experience
  p95:           ≤ 100ms    — catches regional degradation
  p99:           ≤ 300ms    — tail latency boundary

Latency SLI targets (origin fetch, cache MISS):
  p50 (median):  ≤ 150ms   — typical origin round-trip
  p95:           ≤ 500ms   — accounts for distant origins
  p99:           ≤ 1500ms  — tail includes retries

Separating cache HIT and MISS latency SLIs is essential. A single latency target across both creates noise: high cache miss ratios degrade the latency SLI even when the CDN layer itself is performing well. Separate SLIs let you distinguish between CDN performance problems and origin performance problems.

Error Rate SLI

Error rate complements availability by focusing specifically on server-side failures. While availability counts all non-2xx responses, the error rate SLI narrows to HTTP 5xx responses (server errors), excluding 4xx client errors that indicate client problems rather than service problems. This distinction matters because a spike in 404s from a bot scanning for vulnerabilities should not trigger an availability alert.

Freshness SLI

Unique to CDN infrastructure, the freshness SLI measures how often users receive stale content — content that has been updated at the origin but not yet propagated to edge caches. Freshness is computed as the proportion of requests served within the configured TTL of the cached object. A freshness SLI target of 99.5% means no more than 0.5% of requests should receive content older than the intended cache lifetime, an important consideration for cache invalidation workflows.

Setting Meaningful SLO Targets

The most common mistake in SLO definition is setting targets based on aspiration rather than data. A 99.99% availability SLO sounds impressive, but if the current system achieves 99.95%, the gap represents a 5x reduction in allowed failures that may require significant infrastructure investment. Start from historical performance data.

To set a data-driven SLO, collect at least 90 days of SLI measurements and compute the actual performance baseline. If the system has achieved 99.97% availability over the past quarter, setting the SLO at 99.95% creates a realistic target with a small margin for regression. Setting it at 99.99% creates an aspirational target that will generate constant alerts and erode confidence in the SLO system.

SLO windows also require deliberate choice. Rolling windows (typically 30 days) smooth out transient spikes and reflect the ongoing user experience. Calendar windows (monthly, quarterly) align with business reporting cycles. Most CDN operations use 30-day rolling windows for operational SLOs and calendar quarters for business reporting and SLA calculations.

Error Budgets: Spending Reliability Wisely

The error budget is the most powerful concept in the SLO framework because it transforms reliability from a constraint into a resource. The budget equals the distance between 100% and the SLO target, expressed as allowable failures over the measurement window.

For a 99.95% availability SLO over 30 days, the error budget is 0.05% of total requests or time — approximately 21.6 minutes of downtime or 5 million failed requests per 10 billion served. This budget is not waste to be minimized; it is a resource to be invested. Every deployment, configuration change, and infrastructure migration carries some risk of consuming budget. The error budget framework makes this trade-off explicit and manageable.

Budget-Based Release Policies

Error budgets drive concrete operational policies. When budget consumption is normal (below 50%), teams deploy freely and take calculated risks on new features. As consumption increases, policies tighten progressively:

Green zone (0-50% consumed): Normal deployment velocity. Feature releases, configuration experiments, and infrastructure changes proceed with standard review processes. This is the zone where innovation happens — reliability is healthy enough to absorb risk.

Yellow zone (50-75% consumed): Increased scrutiny. Deployments require additional review, canary percentages decrease, and rollback thresholds tighten. Non-critical configuration changes are deferred. The team investigates what consumed the budget and whether it was expected (a planned migration) or unexpected (a silent degradation).

Red zone (75-100% consumed): Reliability-first mode. Only bug fixes and reliability improvements deploy. Feature work pauses. The entire engineering focus shifts to understanding and reducing the failure rate. If the budget exhausts completely, a formal incident review determines root causes and mitigation steps before normal deployment resumes.

This graduated approach prevents the false dichotomy between “ship everything” and “freeze everything.” Teams can ship aggressively when reliability is strong and pull back organically when it degrades, without subjective debates about whether the system is “stable enough” for a deployment.

Implementing SLO Monitoring for CDN

SLO monitoring requires infrastructure that computes SLI values continuously, compares them against SLO targets, tracks error budget consumption, and alerts at appropriate thresholds. The monitoring stack needs to handle CDN-scale data volumes — billions of log lines per day from hundreds of edge PoPs — while producing SLI calculations within minutes of events occurring.

A practical implementation uses CDN access logs as the data source. Each log entry contains the timestamp, HTTP status code, response time, cache status, and PoP identifier. A stream processing pipeline (Kafka + Flink, or a managed equivalent like Datadog or Google Cloud’s SLO monitoring) aggregates these entries into windowed SLI calculations per PoP and globally.

-- Example SLI calculation query (simplified)
-- Availability SLI: 30-day rolling window
SELECT
  DATE_TRUNC('hour', timestamp) AS hour,
  COUNT(CASE WHEN status_code < 500 THEN 1 END)::FLOAT
    / COUNT(*)::FLOAT * 100 AS availability_pct,
  COUNT(CASE WHEN response_time_ms <= 100 THEN 1 END)::FLOAT
    / COUNT(*)::FLOAT * 100 AS latency_p95_met_pct,
  COUNT(*) AS total_requests
FROM cdn_access_logs
WHERE timestamp >= NOW() - INTERVAL '30 days'
  AND is_valid_request = TRUE
GROUP BY DATE_TRUNC('hour', timestamp)
ORDER BY hour DESC;

Multi-Window, Multi-Burn-Rate Alerting

Traditional threshold-based alerting (“alert if error rate exceeds 1%”) generates too many false positives for SLO monitoring. A brief spike to 2% error rate may not threaten the 30-day budget, while a sustained 0.1% elevation over days can exhaust it silently.

Multi-window, multi-burn-rate alerting solves this by combining short and long observation windows with budget consumption rates. A “burn rate” of 1x means consuming the error budget at exactly the rate that exhausts it by the end of the window. A 14.4x burn rate exhausts the budget in 2 days instead of 30.

Effective alerting combines fast and slow burn detection. A fast-burn alert (14.4x burn rate sustained over 1 hour, confirmed over 5 minutes) catches acute incidents. A slow-burn alert (3x burn rate sustained over 6 hours, confirmed over 30 minutes) catches gradual degradation. This dual approach eliminates the tension between detecting fast and slow failures while maintaining low false-positive rates, following the same principles that drive effective CDN observability.

Tiered SLOs for Content Types and Regions

A single global SLO is a poor fit for CDN infrastructure because different content types and geographic regions have fundamentally different performance characteristics. Static assets served from edge cache should be faster and more reliable than dynamic API responses that require origin computation. Users in regions with dense PoP coverage experience lower baseline latency than users in emerging markets with sparse edge infrastructure.

Tiered SLOs acknowledge these differences by setting separate targets per dimension:

Tier 1 — Static assets (images, CSS, JS, fonts):
  Availability: 99.99%  |  p50: ≤ 20ms  |  p99: ≤ 100ms

Tier 2 — Cacheable HTML (marketing pages, blog posts):
  Availability: 99.95%  |  p50: ≤ 50ms  |  p99: ≤ 300ms

Tier 3 — Dynamic content (API responses, personalized):
  Availability: 99.9%   |  p50: ≤ 150ms |  p99: ≤ 1000ms

Regional adjustments (applied as multipliers):
  North America / Europe: 1.0x (baseline)
  Asia-Pacific:           1.2x latency targets
  South America / Africa: 1.5x latency targets

Tiered SLOs prevent a scenario where a global p99 target of 200ms is routinely violated by origin-fetched API responses, drowning out alerts about actual CDN edge degradation. Each tier has its own error budget, enabling independent reliability management for different content delivery workloads.

Organizational Integration

SLOs only work when they drive decisions beyond the engineering team that operates the CDN. Product managers should reference error budget status when prioritizing feature work versus reliability improvements. Business leadership should understand that error budget policies protect revenue — every minute of CDN downtime has a measurable impact on conversion rates, ad impressions, and user engagement.

Monthly SLO reviews bring engineering, product, and business stakeholders together around a shared reliability narrative. The review covers: which SLOs were met and which were missed, how the error budget was consumed (planned changes versus incidents), what actions the budget policy triggered, and any proposed adjustments to SLO targets for the next period.

The most common organizational failure is treating SLOs as engineering metrics that only the SRE team cares about. When SLOs inform product prioritization, infrastructure investment, and customer communication, they become the shared language of reliability that enables organizations to make informed trade-offs between speed and stability. This integration transforms CDN reliability from a technical concern into a business capability — one that can be measured, managed, and improved with the same rigor applied to any other business metric.