Cache analytics is often reduced to a single hit ratio, but that number can hide more than it reveals. A CDN handles many distinct outcomes: a fresh object served immediately, a miss fetched from origin, a request deliberately bypassing cache, a stale object revalidated, a stale response served during origin trouble, or an error generated before a cache lookup is meaningful. Combining them into “hit” and “not hit” loses the causes engineers need to improve delivery.

The right approach starts with a clear cache outcome taxonomy, then measures each outcome by route, object class, geography, response size, and configuration version. The result is not merely a better dashboard. It is a way to connect cache behavior to user latency, origin load, resilience, and cost.

Define the outcomes before calculating ratios

HIT

A hit normally means the edge found a reusable response and served it without contacting the origin for the object. It may still involve shield tiers or internal lookups, so the exact definition should be documented. Fresh hits are usually the fastest and most origin-efficient outcome.

MISS

A miss means the requested representation was not available for reuse at the relevant cache layer. The CDN typically contacts an origin or upstream cache, stores the response if eligible, and serves the client. A miss is not automatically bad. The first request for a new object must miss, and low-popularity content may never receive a second request before expiration.

BYPASS or PASS

A bypass occurs when policy intentionally avoids using a cached response. Common reasons include authorization, cookies, request methods, cache-control directives, configured rules, or an application decision. Bypass traffic should be analyzed separately from misses because increasing time to live will not fix a policy-driven bypass.

REVALIDATED

Revalidation checks whether a stale cached object is still valid, often through a conditional request. A successful validation can avoid transferring the full object while still contacting the origin. It is therefore cheaper than a full miss but more expensive than a fresh hit.

STALE and ERROR FALLBACK

Some CDNs can serve stale content while revalidating or when the origin is unavailable. These outcomes can improve resilience, but they may indicate an upstream problem or freshness tradeoff. Track them explicitly and connect them to content requirements.

Use more than one cache metric

Request hit ratio is the percentage of eligible requests served as hits. Byte hit ratio measures how many response bytes came from cache. Origin offload measures how much request or byte volume did not reach origin. These metrics can move differently. A site may have a high request hit ratio while large video files miss, producing poor byte offload and high origin bandwidth.

Also measure revalidation rate, bypass rate, stale-serve rate, fill error rate, and cacheable-response rate. A falling hit ratio is much easier to diagnose when the dashboard shows whether misses, bypasses, or uncacheable responses increased.

Segment by content and route

A global ratio mixes assets with very different caching intent. Versioned static files may target near-perfect repeat hits. Product pages may have short freshness windows. Personalized API responses may be intentionally uncacheable. Group events into controlled classes such as static assets, media, public API, HTML, authenticated API, and error responses.

Route groups and cache-policy identifiers make comparisons stable. Raw paths can create millions of series and can hide that one route pattern changed. Record a configuration or ruleset version so an observed shift can be tied to a deployment rather than guessed from time alone.

Explain misses instead of merely counting them

A useful miss taxonomy includes cold object, expired object, evicted object, fragmented cache key, purge, regional first request, shield miss, and uncacheable response. Not every provider exposes these directly, but teams can infer some from object age, time to live, cache key dimensions, purge timestamps, shield outcomes, and repeat-request patterns.

Cache-key fragmentation is a common source of hidden misses. Query parameters, cookies, headers, device variants, compression, and localization can create many representations of the same logical resource. Log approved key dimensions or a safe key hash, then measure how many variants exist per route and how traffic is distributed among them.

Connect cache outcomes to latency

Compare latency percentiles by cache state. Fresh hits should usually form a low-latency baseline. Misses add origin connection and processing time. Revalidations may have low bytes but high time to first byte. Bypasses can reveal application paths that never benefit from edge storage. Stale responses may be fast even while the origin is unhealthy.

Do not compare only averages. Cache misses are often a minority, so an average can look healthy while the miss path has a damaging tail. Use percentiles and enough volume to avoid unstable conclusions. Split by region and object size where those dimensions materially affect delivery.

Watch the denominator

Hit ratio should normally exclude requests that are not eligible for caching, but teams must agree on that definition. Including POST requests, authenticated routes, policy bypasses, and non-cacheable errors can make a good cache policy look ineffective. Excluding too much can create an artificially flattering metric. Publish the numerator and denominator rules alongside the chart.

Sampling can also bias the denominator if it is not uniform. A stream sampled by request type, geography, or provider condition may not support a simple global ratio. Use weighted calculations when sampling rates differ and retain the sampling metadata in each record or partition.

Analyze change safely

When changing time to live, cache keys, purge behavior, or stale policy, establish a baseline and compare matched cohorts. A deployment can change traffic mix at the same time as cache behavior. Compare the same route groups, regions, status classes, and object sizes before and after the change.

Look for second-order effects. A higher hit ratio should reduce origin requests, but it may increase staleness risk or cache storage churn. A lower revalidation rate may reduce origin load, but only if freshness requirements remain satisfied. Cache analytics should connect technical outcomes to the content’s intended behavior.

Build an investigation view

  1. Start with hit, miss, bypass, revalidated, stale, and error outcomes over time.
  2. Split the change by route group and content class.
  3. Compare latency, bytes, and origin requests for each outcome.
  4. Inspect cache-policy version, key dimensions, age, and time to live.
  5. Check purges, deployments, origin errors, and traffic shifts in the same window.
  6. Sample individual request IDs to confirm the aggregate explanation.

Common mistakes

  • Optimizing a global hit ratio without separating cacheable and intentionally uncacheable traffic.
  • Treating bypasses as misses and recommending a longer time to live.
  • Ignoring byte hit ratio and origin bandwidth.
  • Comparing providers without aligning outcome semantics and cache layers.
  • Using raw path as a dashboard dimension and creating excessive cardinality.
  • Assuming every miss is avoidable or every hit is correct.

Turn analytics into action

Cache analytics should end with a controlled change: simplify a cache key, remove an accidental bypass, version static assets, adjust a freshness policy, improve shield placement, or fix an origin response that prevents storage. Each change needs a success metric and a rollback condition. The edge log analytics guide provides a broader framework for moving from raw events to decisions.

A good cache program balances speed, freshness, resilience, and origin efficiency. Detailed outcomes make that balance visible. Instead of celebrating or blaming one hit ratio, teams can explain which requests used cache, why others did not, what the user experienced, and which configuration change is most likely to help.