CDN monitoring should answer whether users are receiving the intended response, within the expected time, from a delivery path that remains healthy and observable. Traffic volume is context, not a reliability objective. A useful monitoring system separates user outcomes, CDN behavior, origin behavior, and logging-pipeline health.
Four monitoring layers
User outcomes
Eligible success rate, latency compliance, freshness, correctness, and delivered bytes for a defined service population.
Delivery behavior
Cache outcomes, edge-generated responses, protocol mix, routing tier, geographic distribution, and policy actions.
Origin health
Origin request rate, connection failures, first-byte timing, response status, pool selection, and transfer behavior.
Data validity
Log freshness, coverage, sample rate, duplicate rate, parser errors, unknown values, and aggregation delay.
A compact metric set
| Metric | Recommended segmentation | Reason |
|---|---|---|
| Eligible request success | service, route group, provider, broad region | Measures the user-facing contract without mixing unrelated traffic |
| Latency compliance | route class, cache class, response-size band | Shows the fraction of requests completing below an agreed threshold |
| Cache outcome rate | eligibility, content class, key version | Explains origin offload and configuration change |
| Origin request and error rate | origin pool, route, edge region | Separates upstream impact from edge behavior |
| Delivery lag | provider, adapter, dataset | Determines whether monitoring data is fresh enough to act on |
| Unknown classification rate | schema, adapter, provider | Reveals drift before it corrupts service metrics |
Define SLIs before alert rules
An availability SLI needs an eligible request population, a good-event rule, and explicit exclusions. A latency SLI needs a timing field whose boundary matches the user experience and a threshold appropriate to the route class. A freshness SLI may use object age, purge completion, or version propagation. Write these definitions as versioned code and documentation.
Do not silently improve an SLI by excluding difficult traffic. Exclusions should represent requests outside the service contract, such as known internal probes or malformed inputs, and should be reviewable. Keep the good and total counters available so changes in the denominator are visible.
Build a dashboard that supports investigation
The first row should show user outcomes and data validity. The next row should split error and latency by result source, cache class, route group, provider, and region. A third row can show origin timing, policy actions, bytes, and configuration changes. Include volume with rates and percentiles so low-traffic noise is obvious.
Use matched filters across panels. If the SLI covers production API routes, the cache and origin panels should show that same request population. A dashboard that changes population from chart to chart creates misleading narratives during incidents.
Alert on significant budget consumption
Pages should represent meaningful user impact that requires immediate action. Error-budget burn-rate rules are often more robust than static error thresholds because they account for the service objective and combine severity with duration. Use a fast window for severe incidents and a slower window to confirm sustained impact.
Create tickets or review signals for gradual degradation, rising bypass rates, a low-volume regional tail, or data-quality drift. A notification has value only when it reaches an owner with a documented action. Include the service, affected cohorts, result source, current data validity, and links to representative event searches.
Make incomplete telemetry visible
Cross-check log-derived totals against a second source such as provider metrics, routing counters, or origin summaries. Exact equality may not be expected, but divergence beyond a documented range should be investigated. Record sampling and weight estimates correctly when sampling rates differ.
A monitoring implementation sequence
- Choose one coherent user-facing service.
- Define eligible requests and good outcomes.
- Normalize route, result, cache, region, and provider dimensions.
- Derive low-cardinality counters and histograms using event time.
- Validate coverage, duplicates, lag, and classification quality.
- Set an objective and implement page and ticket severities.
- Attach a dashboard and runbook using the exact SLI population.
- Replay past incidents and review missed or noisy alerts.
For a complete worked approach, read From CDN Logs to SRE Alerts. For timing investigations, use the origin latency workflow.
Build alerts on trusted indicators, not raw noise.
Start with a clear event model, then derive the bounded metrics and data-quality signals your SLOs require.