A CDN status page can show 100 percent uptime while users in one region quietly receive stale or broken content, because aggregate metrics confirm the edge is responding, not what it's actually returning. Log-level monitoring closes that gap, and this guide takes you from zero log access to a working dashboard in a single session.
TL;DR
- CDN status pages confirm the edge is responding; logs show what each request received
- Four signals matter first: cache hit ratio, TTFB, error rate (4xx/5xx split), and throughput
- Log schemas differ by provider; normalization at ingest is the prerequisite for multi-CDN visibility
- A four-panel dashboard catches most delivery problems before users file tickets
- Dedicated log platforms pay off above 100 million requests per day; native CDN analytics cover lower-traffic teams
What CDN Monitoring Actually Means at the Log Level
The uptime check tells you the edge responded. It does not tell you what the edge returned, how fast it delivered the response, or whether content came from cache or origin.
Every HTTP request your CDN handles generates a log line. That line carries the cache status (hit, miss, or bypass), the response code, and time to first byte. It also records the serving edge location and bytes transferred. Aggregate these across millions of requests and you can see what your CDN is doing at any given moment. Without them, you have only a summary of the activity rather than the live events.
Native CDN analytics tools typically surface hourly summaries or sampled data. APM Digest shows that teams needing deep troubleshooting export logs to third-party platforms for sub-second query speeds on petabytes of data and long-term retention. Exporting logs provides the depth of a full instrument panel rather than just a warning light.
The first practical obstacle is volume. A mid-size streaming platform can generate hundreds of gigabytes of CDN logs per day.
The Signals to Capture Before Anything Else
Four signals matter before everything else.
Key CDN Metrics
- Cache hit ratio at or above 95 percent is the target for static content, with 80 to 94 percent workable for mixed content. Anything below 60 percent usually indicates a configuration problem, a short TTL, or content structure issues to address before scaling further.
- Error rate, split by status code type, tells two different stories. 4xx errors indicate clients requesting missing or moved resources. 5xx errors indicate the origin is failing. Treating them as a single "error rate" metric hides which problem you have.
- Time to First Byte (TTFB) at the edge, tracked at percentiles rather than averages. P50 around 150ms, P95 around 400ms, and P99 around 800ms are reasonable baselines to start from. The P99 figure matters most because it captures the slowest requests, where users are most likely to stop waiting.
- Throughput by provider and edge location. Sudden drops in bytes delivered surface delivery failures that error codes alone miss.
Three probing dimensions give you the full picture: user-to-edge for cache use, user-to-origin for a baseline without the CDN, and origin-to-edge to verify that cache misses route correctly (ThousandEyes). The four signals above cover most of what you need on day one.
Where Your CDN Logs Live and How to Get Them Out
Real-time Streaming vs Batch Delivery
Most CDN providers offer two export paths. Cloudflare Logpush, Akamai DataStream 2, and Fastly's real-time streaming API deliver logs with single-digit second latency. CloudFront can push to S3 or Kinesis Data Firehose for near-real-time delivery.
Batch export is simpler to configure but introduces lag. For a first setup, batch is an acceptable starting point. For alert coverage that fires before users complain, you need logs arriving in seconds.
Schema Normalization Across Providers
Running two CDN providers simultaneously means dealing with two different log schemas right away. Akamai and Cloudflare name their fields differently. "Cache status" in one provider's logs may appear as "x-cache" or "cache-control" in another's. IETF RFC 7336 defines a structure for cross-CDN log exchange, but actual provider implementations diverge significantly from any common standard.
The practical fix is to define a canonical schema at ingest time. Per-vendor transforms map each provider's field names to your standard column names. A virtual column tags each record with its source provider. Querying across providers then becomes a SQL task instead of an ETL task. The Fastly log integration shows one example: connector configuration and field mapping from a real streaming CDN into a queryable store.
Massive log volumes and the need to transform data in real time are the main obstacles in multi-CDN monitoring (APM Digest). Schema normalization resolves one. Storage architecture resolves the other.
The Minimum Dashboard Worth Building on Day One
The Four Panels
Start with four queries, one per panel:
- Cache hit ratio over a rolling time window, grouped by edge location. A ratio drop in a single PoP while others hold steady points to a localized misconfiguration rather than a global problem.
- Error rate, split by 4xx and 5xx, plotted over time. Keep them on separate lines. A 4xx spike usually follows a deployment with broken URLs. A 5xx spike means the origin is struggling.
- TTFB by edge location. Map this geographically if your tool supports it. A single region spiking while others stay flat is the pattern that would have surfaced the cache misconfiguration from the opening six hours sooner.
- Throughput by CDN provider, in bytes per second. If you run multiple providers, this panel tells you which one is carrying load and which one is failing to deliver.
Why Normalization Changes the Economics
Paramount consolidates logs across Akamai and Fastly into a single normalized table. Multi-schema tables and SQL transforms standardize the inconsistent field names at ingest time. Infrastructure spend dropped by over 50 percent and data retention increased 6x, according to Hydrolix's multi-CDN case study, compared to their previous setup. The reduction came from eliminating duplicate storage across vendor-specific tooling.
Teams use Hydrolix CDN Insights to query a single normalized table across Akamai, Cloudflare, CloudFront, Fastly, and Tencent, providers that together account for roughly 80 percent of global CDN traffic. The dashboard you build on day one against that table is the dashboard you scale.
The Alerts to Wire Up Before You Do Anything Fancier
Three alerts belong in place before any advanced automation:
- Cache hit ratio dropping more than 10 percentage points below your 7-day average and staying there for more than 5 minutes. Brief dips are noise. A sustained drop means something changed: a deployment, a TTL setting, or a misconfigured edge rule.
- 5xx error rate exceeding 1 percent of total requests over a 2-minute window. This catches origin failures before the origin team's own monitors fire. CDN logs capture the user-facing effect while origin metrics capture the server-facing cause.
- Throughput collapse on a single CDN provider, defined as a 40 percent drop from the previous hour's average. A sustained collapse is usually the first sign of a provider-level delivery failure. It shows up in bytes-delivered data before error rates catch up.
Wiring these alerts to full log data rather than sampled summaries changes what they can detect. TrafficPeak detected a DDoS attack at Elkjøp Nordic during Black Friday, identifying 3,000 IP addresses across 80 countries before users were affected. Every request was present in the log stream. Sampled data at that traffic volume would have smoothed the spike into baseline noise.
A Short Maturity Ladder: from First Dashboard to Full Visibility
Stage 1: Add P95 and P99 latency breakdowns by geography. Group TTFB percentiles by country or region. The first time you run this query, you will usually find one region in the P99 bucket while others sit at P50. That finding typically surfaces a misrouted edge location or an underprovisioned PoP.
Stage 2: Extend retention beyond 30 days without sampling. Most teams start with 7 to 14 days of log data, enough for weekly comparisons. Moving to 90 days or longer reveals seasonal patterns, builds a reliable alert baseline, and makes incident post-mortems useful. Hydrolix CDN Insights stores 15-plus months of full-fidelity data without sampling. All historical records stay queryable at sub-second latency on petabyte-scale datasets, with no re-hydration step.
Stage 3: Connect CDN logs with origin and player data. A cache miss that coincides with an origin response time spike lets you trace user-visible latency to its source layer rather than guessing.
One scope boundary worth naming: below roughly 100 million requests per day, built-in CDN reporting covers the signals that matter. The work of streaming ETL, schema normalization, and columnar storage only pays off when simpler tools start breaking under the data load. Start with native tooling and revisit when queries begin timing out.
Start Your CDN Monitoring with Hydrolix CDN Insights
The architecture this guide describes scales further than most teams will ever push it. During the 2025 Super Bowl, Hydrolix CDN Insights processed nearly 200TB of FOX Sports log data. Average query response time across 55 billion records was 0.481 seconds. Ingest-to-visibility ran at 5 to 10 seconds at tens of millions of events per second. That's what the platform looks like at the ceiling. For teams that have outgrown native CDN analytics, it's the same normalized, multi-provider table you built on day one, just at a different order of magnitude.
For teams on Akamai, TrafficPeak, Hydrolix's managed service on Akamai Cloud, delivers the same architecture at 75 percent lower cost than comparable providers. Full-fidelity retention becomes practical rather than expensive.
The CDN Insights solution page and the multi-CDN best practices guide are the right next steps for teams ready to move beyond their first dashboard.
Moving Beyond the Status Page
A status page tells you the edge is responding. Log-level monitoring tells you what the edge is returning, to which users, from which location, and whether the content came from cache. Those are different questions. A team with the four-panel dashboard from this guide would have seen that cache misconfiguration in the cache hit ratio panel within 30 minutes. The first support ticket would never have been necessary. That's the full distance between a green indicator and genuine visibility into what your CDN is doing.
Which is better for CDN monitoring: real-time streaming or batch export?
Real-time streaming is necessary for operational alerting because it delivers logs in seconds, allowing you to catch cache misconfigurations or origin failures before users report them. Batch export is easier to set up but introduces a lag of several minutes to an hour, making it better suited for long-term trend analysis rather than incident response.
What does a cache hit ratio below 60 percent indicate?
A ratio below 60 percent typically indicates a configuration error, such as a too-short Time to Live (TTL) or an origin that is incorrectly sending no-cache headers. According to Last9, while 95 percent is the gold standard for static content, a drop below 60 percent suggests the CDN is failing to offload traffic, which will likely spike your origin costs.
When should I use synthetic monitoring versus log analysis?
Synthetic monitoring is best for outside-in verification of regional availability and DNS routing, while log analysis provides the inside-out view of what actually happened to every user request. Practitioners often use synthetic probes to detect "ghost" regional failures that aggregate log metrics might smooth over, but rely on logs for deep forensic troubleshooting of specific 5xx error spikes.
At what traffic volume do native CDN analytics become insufficient?
Native analytics typically become a bottleneck around 100 million requests per day, where sampled data and hourly summaries hide critical P99 latency spikes. Teams at this scale, such as FOX Sports, move to dedicated log platforms to maintain sub-second query speeds on petabytes of full-fidelity data without the limitations of pre-aggregated vendor reports.
