Lifecycle of an HTTPS request, with the CDN edge broken out. Running example: a shopper in Madrid on amazon.com going through the checkout page, served through Cloudflare as the CDN in this illustration.
Fresh object in the POP. Origin never touched.
Falls through to the tiered cache before the origin.
No single product sees the whole path. Correlating all four is the Datadog play.
Click any box (and the four stages inside the CDN edge) for details. Each includes two lenses: what the user feels when that step slows down, and what an SRE / DevOps engineer checks and does.
Select a box in the diagram to see what happens there, in depth, with the amazon.com checkout example. Start with the CDN Edge POP and its four inner stages for the most detail.
The terms that show up in CDN logs, metrics, and dashboards, and why each one matters when you are debugging.
A global network of caching servers that sits between users and the origin, serving content from close to the user. Cloudflare, Fastly, Akamai.
Watch: cache-hit ratio, edge latency, offload %.A CDN data center near the user. The first (often only) server the browser talks to; TLS terminates and caching happens here.
Watch: latency + error rate per POP and region.One IP announced from many POPs; the network routes each user to the nearest one. How most modern CDNs steer traffic.
Watch: which POP a region is landing on (mis-routing = latency).The customer's own servers, the source of truth. Reached only on a cache miss or for dynamic/uncacheable requests.
Watch: origin-fetch time and origin request volume.A middle cache tier that consolidates edge misses into one origin fetch, protecting the origin from stampedes.
Watch: mid-tier hit ratio; a spike in origin RPS = shield miss.The outcome of a cache lookup: served from edge (HIT), fetched from deeper (MISS), served expired (STALE), or never cached (BYPASS, e.g. checkout).
Watch: cache-status distribution by path.Share of requests served from cache. The single most important CDN health + cost metric; a drop means slower pages and a hotter origin.
Watch: hit ratio trend; alert on sudden drops.How long an object stays fresh, set by origin headers (Cache-Control, s-maxage). Controls freshness vs load.
Watch: object age; a shortened TTL can tank hit ratio.What makes a cached object unique (URL + selected headers/cookies/query). A bad key fragments the cache.
Watch: low hit ratio on a path often = a cookie or Vary in the key.Evicting cached objects on demand (by URL or tag), e.g. after a price change, so users do not see stale content.
Watch: purge events correlated with a temporary hit-ratio dip.The edge completes HTTPS and decrypts, so it can cache/inspect/log, then re-encrypts to the origin.
Watch: handshake time, HTTP/2 vs HTTP/3, resumption rate.Edge rules that block malicious requests (SQLi, XSS) before they reach the origin.
Watch: blocked vs allowed by rule; false positives hurt conversion.Scoring + acting on automated traffic (often ~40% of requests): allow, challenge, or block. Big for scraping, scalping, card-testing.
Watch: bot score distribution, challenge rate on real users.Capping abusive request volume per IP/token and absorbing floods at the edge.
Watch: rate-limit actions, L3/L7 attack traffic vs baseline.Serverless code at the POP (Workers, Compute@Edge, EdgeWorkers): rewrites, auth, personalization, waiting rooms.
Watch: function latency, CPU time, error rate, subrequests.The CDN shipping per-request edge logs to a destination (like Datadog) in near real time. High volume, mostly unindexed.
Watch: ingest volume + cost vs how much is actually indexed.Share of bytes/requests the CDN served without touching the origin. High offload = fast + cheap + resilient.
Watch: bytes from edge vs origin.Three complementary views: edge logs/metrics (the CDN), synthetics (scripted probes), and RUM (real users). Each sees a different slice.
Watch: reconcile all three when they disagree.The roles that touch CDN telemetry, what they care about, and the action they typically take.
Most of these roles overlap in a CDN incident: the value is one shared view that ties edge logs/metrics to RUM, APM, and infra so each persona is looking at the same request.
Shoppers report the checkout button spinning for 4-5 seconds and some orders failing. Conversion on /checkout drops and a latency alert fires. Here is how an SRE narrows it down across the layers, using the same request path from the diagram.
Open RUM for /checkout: INP and load time are spiking for many users across devices, browsers, and regions, not one bad phone. Sessions show the wait is on the server response, not client rendering.
Static assets (images, CSS, JS) still HIT with normal edge latency and hit ratio, so the edge is healthy. But /checkout is uncacheable (BYPASS), and its origin-fetch time jumped from ~200ms to ~4s.
Challenge and block rates are at baseline, no DDoS signature, and real users are not being throttled or CAPTCHA'd. The spike is legitimate Prime Day traffic.
Trace the /checkout POST. Most spans are fast and the order-DB write is fine, but the payment-authorization call to the downstream payment service is p99 ~4s. That one span is the whole delay.
The payment service pods are pegged on CPU with connection-pool saturation. A config deploy ~30 minutes before the alert changed the payment client's timeout and retry settings.
The deploy tightened a timeout and added aggressive retries on the payment client. Under Prime Day load, those retries multiplied requests to the payment service, saturating its connection pool so every authorization call slowed to ~4s, which surfaced to shoppers as a spinning checkout.
Roll back the deploy (or fix the backoff and raise the pool). Payment auth latency drops back to ~200ms and checkout recovers. Confirm in RUM that INP on /checkout is back to baseline and error rate is clear.