When users report a slow site or API, “the CDN is slow” and “the origin is slow” are both incomplete explanations. A request passes through several stages: client connection, edge processing, cache lookup, upstream connection, origin work, first byte, and response transfer. CDN logs can separate many of these stages, but only if timing fields are understood, normalized, and compared within the right cohorts.

The diagnostic goal is to locate where additional time entered the path, identify the requests that share that pattern, and connect the change to a deployment, network, cache state, origin pool, or payload characteristic. Start with broad evidence, then narrow to individual request IDs. Avoid jumping from one slow request to a global conclusion.

First confirm the timing semantics

Providers use similar names for different measurements. “Origin time” may mean connect plus response, time to first byte, or the full upstream transaction. “Edge duration” may start at request arrival and end after the last response byte. Some fields are milliseconds, others microseconds or seconds. Read the provider definition and encode the canonical unit in your schema.

Also determine how reused connections appear. DNS, TCP, and TLS timing can be zero or absent when the edge reuses an existing origin connection. That does not mean those stages were instantaneous; it means they did not occur for that request. Treat null, zero, and unavailable as different states where possible.

Separate cache hits from origin-bound requests

Cache hits provide an edge baseline because they do not wait for the application origin. If hit latency is stable while miss and bypass latency rises, the problem likely lies in the upstream path, origin processing, or transfer. If both hits and misses degrade in the same regions, investigate edge capacity, client network conditions, response size, or a broader routing issue.

Do not mix fresh hits, revalidations, shield hits, origin misses, and deliberate bypasses in one percentile. Each follows a different path. Build cohorts by cache outcome and routing tier before comparing latency.

Break the upstream path into stages

Connection setup

Origin DNS lookup, TCP connect, and TLS handshake time reveal network reachability and connection reuse. Rising connect time concentrated in one edge region or origin pool can indicate routing, packet loss, saturation, firewall behavior, or an unhealthy endpoint. A system-wide rise may follow a certificate, protocol, or load-balancer change.

Time to first byte

Origin time to first byte includes upstream network delay plus the time the origin takes to begin responding. It is often the most useful indicator of application or dependency delay. Compare it by route group, status, origin pool, deployment version, and request size. A database-heavy endpoint can degrade while static origin fetches remain normal.

Response transfer

The time between first and last byte depends on object size, origin throughput, streaming behavior, compression, and network conditions. A slow transfer of a large object is different from a 50-byte response that takes a long time to begin. Always pair transfer time with bytes and content class.

Use percentiles and volume together

Averages are easily distorted by traffic mix. Track p50, p90, p95, and p99 with request counts for each cohort. A percentile based on a handful of requests can jump dramatically without representing broad impact. Minimum-volume rules and confidence intervals can keep dashboards honest.

Compare the same population across time. If a release shifts traffic from cached GETs to uncached POSTs, a global latency increase may reflect mix rather than degradation. Route-normalized and cache-state-normalized comparisons are more reliable.

Find the dimensions that explain the tail

Start with route group, status class, cache outcome, origin pool, edge region, response size, and deployment version. Add client geography or protocol only when the initial split suggests they matter. High-cardinality exploration should happen in an event store, not as permanent time-series dimensions.

Rank groups by contribution to slow requests, not just their own percentile. A tiny route with extreme latency may affect fewer users than a moderate regression on a high-volume API. Contribution can be expressed as excess latency multiplied by request count, failed requests, or error-budget consumption.

Correlate request IDs across the stack

Select representative slow and normal requests from the same cohort. Use a propagated request or trace ID to find load-balancer, application, service, database, and external dependency telemetry. The edge log tells you that first byte took 1.8 seconds; a trace may show 1.4 seconds in a downstream inventory call. Without correlation, teams often debate infrastructure layers instead of locating the wait.

Sample both failures and successes. A slow request that ends in 200 can reveal saturation before errors rise. A fast 503 generated by the edge is a reliability problem but not an origin-latency problem. Status and result source keep these cases separate.

Check common latency patterns

  • Connect time rises in one region: inspect origin routing, endpoint health, network path, and connection reuse.
  • First-byte time rises by route: inspect application code, dependencies, queueing, and database behavior.
  • Transfer time rises with bytes: inspect throughput, compression, streaming, and origin egress.
  • Miss latency rises after a purge: inspect cache stampede controls, shield behavior, and origin capacity.
  • Revalidation latency rises: inspect conditional-request handling and metadata lookup at the origin.
  • All cohorts rise after a configuration change: inspect edge functions, routing, TLS, and logging of the change window.

Account for queueing and load

Latency often rises before resource utilization reaches an obvious maximum. Connection pools, thread pools, event loops, database queues, and upstream limits can introduce wait time. CDN logs may not expose those internal queues, but they can show the traffic and timing pattern that triggers them. Compare request concurrency, cache-miss rate, origin request rate, and latency in the same window.

Cold starts and autoscaling can create periodic tails. Group by origin instance class, region, deployment, or scaling event if available. Averages across warm and cold capacity can hide a small but user-visible slow population.

Use server-provided timing carefully

Applications can expose controlled timing measurements in response metadata, allowing the CDN or client telemetry to record stages such as application, database, or template work. These values should use stable names, avoid sensitive descriptions, and be treated as additional evidence rather than a substitute for traces. They also need versioning when internal boundaries change.

Server timing can be especially useful when full distributed tracing is unavailable for every request. A small set of bounded metrics can distinguish application time from upstream network time without adding high-cardinality detail.

A repeatable troubleshooting sequence

  1. Verify event freshness, timing units, and provider field definitions.
  2. Identify the affected user-facing metric and time window.
  3. Separate cache hits, misses, bypasses, and revalidations.
  4. Split total time into connection, first-byte, and transfer stages.
  5. Rank route, origin, region, status, and size cohorts by impact.
  6. Compare matched periods and configuration versions.
  7. Trace representative request IDs across the application stack.
  8. Test a narrowly scoped change and watch both latency and error outcomes.

The CDN monitoring guide shows how to turn these fields into durable dashboards and alerts. The essential habit is decomposition: compare like with like, locate the stage where time changed, and use correlated evidence to move from an edge symptom to a specific upstream cause.

Related field guides