Content Delivery Networks (CDN) improve the speed, reliability, security and global reach of their content. However, enterprises can’t just “set and forget” CDNs and hope for the best. They need to be monitored for performance and security issues just like other critical infrastructure.
Yet many engineering teams rely on default aggregated dashboards that provide basic metrics but don’t have the details necessary to understand what is happening with specific edge servers, regions and ISPs (internet service providers). A generic “99% uptime” status or a flat average latency graph often hides regional outages, errors affecting specific user devices, and inefficient caching policies that quietly increase your origin egress bills. To truly control delivery performance and costs, you must move beyond high-level summaries and monitor the log data generated by your edge infrastructure.
TL;DR
- Averages hide failures: Always track latency using percentiles (p95, p99) rather than averages, which smooth over poor user experiences in specific regions.
- Distinguish hit ratios: Measure “byte hit ratio” to track cost savings and “request hit ratio” to track performance. They are not interchangeable metrics.
- Isolate error sources: Segment error rates by “edge errors” versus “origin errors” as a first step to identify where errors are occurring.
- Cardinality matters: Standard monitoring tools often drop high-cardinality data (like individual user sessions or specific file paths), but you need high-cardinality data for root cause analysis.
The Problem With Default Dashboards
Many CDNs provide a default analytics view. These dashboards are useful for a quick health check, but they typically don’t provide enough detail. The primary issue is aggregation.
When a CDN vendor aggregates data to present a simple chart, they strip away the context required to troubleshoot complex issues. For example, if your global cache hit ratio is 95%, you might assume the system is healthy. However, that average could hide the fact that your Asia-Pacific POPs (points of presence) are operating at 60%, driving up latency for millions of users, while US-based traffic skews the global average upward.
True CDN analytics requires ingesting raw logs and computing metrics that align with your specific goals: performance stability, cost reduction, and security.
Performance Metrics: Beyond “Speed”
When it comes to monitoring CDNs and internet traffic, performance is about the specific timing of the request lifecycle. You need to measure how long the CDN takes to process a request and how long it waits for your origin (for uncached content) and for edge servers to return content (for cached content).
Time to First Byte (TTFB) vs Last Byte
Time to First Byte (TTFB) measures the duration from the user’s request until the first byte of data arrives. This is a strong indicator of network latency and connection setup time. However, TTFB alone is misleading for large payloads like video segments or heavy binaries.
You must also track Time to Last Byte (TTLB) or download time. A fast TTFB with a slow TTLB indicates throughput issues or network congestion during the transfer. By comparing these two, you can isolate whether the bottleneck is connection establishment (handshake/DNS) or bandwidth capacity.
Origin Latency
If a request misses the cache, the CDN must fetch it from your origin. You need to measure origin latency separately from client-facing latency. This metric reveals how long the CDN waits for your backend to respond.
If client latency is high but origin latency is low, the issue is likely within the “middle mile” or the user’s last-mile network. If origin latency spikes, the CDN is doing its job, but your infrastructure is struggling to keep up.
Latency Percentiles
Never rely on average latency. In distributed systems, averages hide outliers. A localized outage affecting 5% of your users barely moves the average, but it represents a catastrophic failure for that segment.
Instead, measure p50, p90, p95, and p99 latency.
- p50 (Median): The experience of a typical user.
- p95/p99 (Tail Latency): The experience of your widespread users or those in challenging network conditions.
Google’s SRE teams emphasize that monitoring tail latency is the only way to catch regressions before they become general outages.
Protocol Usage
Modern CDNs support multiple versions of HTTP and TLS. Analyzing traffic by protocol version helps you understand the efficiency of your delivery.
- HTTP/3 (QUIC): Recent data shows significant adoption, with Cloudflare reporting 21% of requests via HTTP/3.
- TLS Handshake Time: Monitoring the duration of SSL/TLS handshakes can highlight issues with certificate chains or cipher suite mismatches that delay connection setup.
Efficiency Metrics: The Cost Drivers
CDN costs are typically driven by egress bandwidth and request volume. Optimizing these requires a deep understanding of how effectively the CDN is shielding your origin.
Request Hit Ratio vs Byte Hit Ratio
Many teams confuse these two metrics, but they serve different purposes.
- Request Hit Ratio: The percentage of requests served from the edge. This measures performance. A high request hit ratio means users are getting fast responses without waiting for the origin.
- Byte Hit Ratio: The percentage of data (bandwidth) served from the edge. This measures cost efficiency, since retrieving from cache is more cost-effective than retrieving from origin.
A site might have a 99% request hit ratio (serving tiny icons and CSS files from cache) but a 50% byte hit ratio (because large video files or binaries are missing the cache). If your goal is to reduce origin egress fees, byte hit ratio is the metric that matters.
Origin Offload
Origin offload is the percentage of requests that your CDN infrastructures handle without hitting the origin. You should measure offload not just globally, but by origin shield or tiered cache layers.
If you employ a tiered caching strategy (where edge POPs fetch from a central shield POP rather than the origin), you need to measure the hit ratio of that shield layer. A low shield hit ratio indicates that your request collapsing strategy is ineffective, causing unnecessary load on your origin servers. Request collapsing, also known as request coalescing, is the process of “collapsing” multiple requests for the same uncached content into one request from origin. As an example, if a thousand people send a request for the same uncached asset, the edge server will “collapse” those requests so that origin only has to process one request, not one thousand.
Cache Eviction Rates
Why are items missing the cache? It is not always because the content is new. Eviction occurs when the CDN deletes content to make room for more popular items. High eviction rates on valid content suggest your TTL (Time to Live) settings are too aggressive or you are not paying for sufficient cache reserve in specific regions.
Reliability: Isolating the Failure Domain
When your teams see errors, the first question is: “Is this a problem in our application, or is it the CDN?” Your analytics should answer this question instantly. The following metrics are important for getting quick answers.
Edge vs Origin Errors
The first step is to separate error codes (4xx and 5xx) based on what generated them.
- Origin errors: The CDN forwarded the request, and your server returned a 500 or 503. The fix lies in your application code or capacity.
- Edge errors: The CDN failed to process the request (for example, a 502 Bad Gateway from the edge, or a 403 due to WAF rules). The fix lies in CDN configuration, or, if there is a CDN outage or issue and you are incorporating a multi-CDN strategy, you can switch out CDN infrastructure.
Cloudflare, for example, provides specific fields like EdgeResponseStatus vs OriginResponseStatus to make this distinction clear. AWS CloudFront uses x-edge-result-type to categorize the outcome.
Revalidation Rates (304s)
A 304 Not Modified status code is technically a success, but it represents latency. It means the browser asked, “Is this file still good?” and the CDN checked the origin to confirm.
While this saves bandwidth, it still incurs a round-trip delay. High rates of 304s to the origin suggest you could tune your Cache-Control headers (such as using stale-while-revalidate) to serve content faster without the round-trip verification.
Security Dimensions
Security teams often view CDN logs as their first line of defense. Security analytics should track the shape and volume of unwanted traffic.
WAF Events and Rule Triggers
Counting blocked requests is just the first step. You should also analyze which rules are triggering. A sudden spike in SQL injection rule triggers from a single ASN (Autonomous System Number) indicates a targeted attack. Meanwhile, a spike in “Generic Bad Bot” blocks might indicate a scraper targeting your pricing pages. Or it could even suggest that there is a WAF rule blocking “good” bots necessary for SEO, and that you need to update the rule.
Geo and ASN Anomalies
Traffic volume should follow predictable daily patterns based on your user base. Threat hunting relies on detecting deviations from these baselines.
- Geo-blocking leaks: If you restrict traffic to the US, but your analytics show 2% of traffic from sanctioned regions, your geo-blocking configuration has a loophole.
- ASN reputation: Track the percentage of traffic coming from residential ISPs versus cloud hosting providers (AWS, GCP, DigitalOcean). Real users rarely browse from a datacenter IP. High volume from these sources is a strong bot signal.
The Cardinality Challenge
The metrics discussed above require slicing data by many dimensions such as URL path, user agent, IP address, city, ASN, and error code. This is high-volume data, with some fields having high cardinality.
A typical approach to cardinality for many platforms is to aggregate medium- or low-cardinality data (such as region) while discarding high-cardinality data or moving it into frozen storage where it’s difficult to access. The reason for this is simple: traditional data architectures are costly when it comes to storing and retaining high-cardinality data.
Retaining high-cardinality data is important for use cases like root cause analysis and forensic investigation. If latency spikes in France, you need to know which specific file path is causing it. Is it a specific video segment? A new JavaScript deployment? Aggregated metrics won’t give you enough information.
Managing High-Volume Logs
To perform this level of analytics, you typically need to ingest raw CDN logs (through APIs like CloudFront Real-Time Logs, Fastly Log Streaming, or Cloudflare Logpush) into a specialized data platform.
Solutions like Hydrolix are architected specifically for this heavy-lift scenario. By decoupling storage from compute, Hydrolix allows teams to ingest massive streams of high-cardinality CDN logs and retain them for long periods without the high costs associated with traditional observability tools. This enables you to query raw log data to find the “needle in the haystack”—such as a specific user encountering 500 errors on a specific POP—without worrying about cardinality limits.
Conclusion
Effective CDN analytics moves you from a reactive stance (“Is the site up?”) to a proactive one (“Are we optimizing every millisecond and dollar?”). By ignoring averages and focusing on percentiles, separating edge performance from origin performance, and validating cache efficiency with granular metrics, you regain control over your content delivery.
Start by auditing your current dashboards. If you can’t differentiate between an edge error and an origin error, or if you can’t see the latency for the 99th percentile of your users, you have a visibility gap. Close that gap by capturing raw logs and building views that reflect the reality of your user experience.
Next Steps
With CDN Insights, you can start monitoring your CDN infrastructure in minutes. Compare how multiple CDNs are performing at any scale, segment data by region, ASN, and more, and drill down into individual logs for further troubleshooting. You can also keep full-fidelity data long-term (15 months by default) without needing to sample or throw data away.
FAQS About CDN Analytics
What is the difference between RUM and CDN analytics?
Real User Monitoring (RUM) captures performance data from the user’s browser (client-side), measuring the full experience including rendering time. CDN analytics measures performance from the edge server’s perspective (server-side), focusing on delivery, caching, and network transfer. Both are necessary for a complete view of performance.
Why is my cache hit ratio low?
A low cache hit ratio often results from overly restrictive Cache-Control headers, high variability in query strings (which makes URLs look unique), or low traffic volume that prevents content from staying “hot” in the cache. Analyzing the top “missed” URLs usually reveals configuration changes that can improve this metric.
How do I measure origin offload?
Origin offload is best measured by comparing the total bandwidth served to users against the bandwidth fetched from your origin server. A formula often used is (Total Bytes - Origin Bytes) / Total Bytes. A healthy static site should aim for over 90% offload.
What are high-cardinality dimensions in CDN logs?
High-cardinality dimensions are data fields with many unique values, such as User IDs, specific URL paths, Client IP addresses, or unique transaction IDs. Retaining high-cardinality logs is essential for debugging specific incidents and understanding security issues. However, it can be expensive or impossible in traditional monitoring tools that rely on aggregation but throw the underlying raw full-fidelity data away.
Can CDN analytics help detect DDoS attacks?
Yes, CDN analytics provide the earliest signals of DDoS attacks by highlighting sudden spikes in requests per second (RPS), unusual geographic traffic shifts, or surges in specific error codes (like 403 Forbidden). Analyzing the “shape” of the traffic spike helps distinguish between a malicious attack and a viral marketing event.
