A one-point drop in cache hit ratio on a 500 TB/month workload moves roughly 5 TB of traffic back to origin. At typical egress and compute pricing that is a four-figure monthly swing, and most teams do not notice it for weeks because their CDN analytics dashboard reports a blended, account-wide hit ratio that hides the regression inside a single content class. That is the core failure of CDN monitoring tools as most organizations deploy them: aggregate numbers that are technically accurate and operationally useless. This article gives you a 2026-current tool landscape, the threshold values worth alerting on, a cardinality-aware architecture for log pipelines, and the piece almost every comparison skips — cost attribution, now a standard procurement requirement rather than a finance side-quest.
The old article on this URL listed product analytics suites next to log processors as if they solved the same problem. They do not. CDN analytics splits into four distinct telemetry planes, and a tool that is excellent in one is usually mediocre in the others.
What shifted recently: HTTP/3 is now the majority transport for browser traffic on most consumer-facing properties, which breaks assumptions in older log schemas that keyed connection metrics off TCP. If your dashboards still bucket by TCP retransmit rate, you are measuring a shrinking minority of sessions. QUIC connection migration also means a single logical session can appear across multiple edge nodes, inflating unique-connection counts.
Every tool below was checked for active maintenance as of Q1 2026. Several names from the previous version of this article were dropped: general-purpose product analytics platforms measure funnels, not delivery, and putting them in a CDN monitoring list was a category error.
Real user monitoring is where CDN analytics stops being a delivery metric and becomes an experience metric. Three categories are worth your time in 2026:
Session-replay and heatmap tools were in the previous version of this list. They are legitimate UX products but they do not observe delivery. Keep them, do not count them as CDN monitoring tools.
Cache hit ratio analysis fails when it is done at the account level. Segment it, always, along four axes: content class (static assets, video segments, API responses, images), PoP or region, cache tier (edge versus shield), and object size bucket.
Two ratios, not one. Request hit ratio tells you how well you are protecting origin CPU. Byte hit ratio tells you how well you are protecting origin egress spend. They diverge sharply: a video library can post 98% request hit ratio and 91% byte hit ratio because the long-tail misses are large files. Alert on both.
| Content class | Healthy byte hit ratio | Page for investigation | Usual root cause when low |
|---|---|---|---|
| Versioned static assets | 99%+ | Below 97% | Cache key polluted by query strings or cookies |
| VOD segments | 92–97% | Below 90% | Catalog exceeds edge storage; needs shield tiering |
| Live HLS/DASH | 85–95% | Below 80% | No request collapsing on manifest fetches |
| Images with dynamic transforms | 88–95% | Below 85% | Unbounded variant space from client-supplied dimensions |
| Software and game binaries | 95–99% | Below 93% | Range requests fragmenting objects across nodes |
One more status worth isolating: revalidated hits. A 304 from origin is a hit for byte accounting and a miss for origin request load. Tools that fold revalidations into the hit bucket will tell you origin is fine while your origin sits at 70% CPU.
This is the section the current page-1 results largely omit. Since 2025, delivery spend visibility has moved from a finance request to a procurement gate, driven by FinOps practices reaching platform teams and by multi-tenant SaaS products needing per-customer margin data.
The pattern that works: enrich edge logs at ingest with a tenant or product dimension derived from hostname, path prefix, or a signed token claim. Store bytes-served and request-count aggregates in a daily rollup table keyed on that dimension plus region and cache status. Join against your contracted rate card to produce cost-per-tenant, cost-per-gigabyte-delivered, and — the metric that actually drives decisions — cost-per-origin-miss.
That last one is the lever. If a tenant costs $0.004 per GB delivered but their misses pull origin egress at $0.05–0.09 per GB from a hyperscaler, a 5% miss rate roughly doubles their true delivery cost. Cache hit ratio analysis and cost attribution are the same investigation viewed from two ends.
Rate-card asymmetry matters here. Hyperscaler CDN pricing in 2026 still runs in the $0.05–0.085 per GB range in North America and Europe for standard tiers, before request fees. Volume-oriented providers sit an order of magnitude below that. BlazingCDN's pricing tiers start at $100/month for 25 TB with additional gigabytes at $0.004, and step down to $4,000/month for 2,000 TB with additional gigabytes at $0.002 — roughly $2 per TB at the top tier. For teams running the cost-attribution model above, that spread is the difference between a delivery line item that scales linearly with growth and one that flattens. BlazingCDN backs it with 100% uptime, NVMe SSD edge storage, and stability and fault tolerance comparable to Amazon CloudFront while being materially cheaper at enterprise volume.
Teams push edge logs into a metrics system with PoP, status code, host, and path as labels. Path is unbounded. The time-series database ingests millions of series, query latency degrades, and the monitoring stack fails during the incident it was built to catch. Keep high-cardinality dimensions in the log store, keep metrics to bounded labels only.
Several providers silently increase log sampling under load. Your 5xx rate looks flat during the exact window you need it most. Validate by reconciling logged request counts against billed request counts monthly; a persistent gap means sampling.
A single degraded node inside a large region moves the regional p50 by almost nothing while p99 for affected users triples. Alert on per-PoP p99 with a comparison to the region median, not on regional averages.
Edge timestamps, origin timestamps, and RUM beacon timestamps drift. When you correlate a client-reported slow load with edge logs and find nothing, check skew before checking the CDN.
There is no single number. Versioned static assets should clear 99% byte hit ratio, VOD segments 92–97%, live streaming 85–95%. Any account-wide figure quoted without content-class segmentation is not actionable.
For CDN analytics specifically, a self-built beacon reading navigation timing plus a Server-Timing header carrying cache status and PoP covers most of what you need. Commercial real user monitoring earns its cost when you want session correlation, error grouping, and mobile SDK coverage alongside delivery metrics.
Thirty days of raw request logs for incident forensics, thirteen months of daily rollups for capacity planning and year-over-year comparison. Raw logs beyond 90 days are almost never queried and dominate storage cost.
Enrich logs at ingest with a tenant identifier from hostname, path prefix, or signed token claim, then aggregate bytes and requests daily against your rate card. Track cost-per-origin-miss separately, since origin egress usually dominates true delivery cost for low-hit-ratio tenants.
Common causes: the provider counts revalidations as hits while you count them as misses, log sampling under load, timezone boundary differences in daily rollups, and internal health-check traffic included in one view but not the other. Reconcile against billed totals to find which.
Yes, if you normalize schemas at ingest. Map each provider's cache-status vocabulary to a common set, standardize PoP naming, and key everything on a shared request identifier where available. Player-side and browser RUM is the only layer that compares providers on an identical basis without normalization work.
Pick your single highest-volume content class. Pull last month's edge logs, compute request hit ratio and byte hit ratio separately for that class, then break both down by PoP and by object-size bucket. If the two ratios differ by more than five points, or if any PoP sits more than three points below the median, you have found real money. Then multiply your miss bytes by your origin egress rate and put that number next to your CDN invoice.
What did your byte-versus-request hit ratio gap turn out to be, and which axis surfaced the regression first? That comparison is the fastest diagnostic in CDN analytics, and almost nobody runs it on a schedule.