Choose the relevant hostname and UTC period. Identify whether each report counts requests, visitors, events, bytes or application sessions, and note any sampling or plan-specific data limitations.

1. Open the appropriate Cloudflare zone analytics view and filter to the hostname, path and period being investigated.
2. Separate cached responses, edge security actions and requests sent to the origin where the available metrics allow.
3. Inspect the hosting access logs for the same period and account for timezone, log rotation and multiple origin servers.
4. Correlate request IDs or Ray IDs where your trusted proxy-aware logging records them. Avoid trusting arbitrary visitor-supplied forwarding headers.
5. Explain remaining differences using cache hits, blocked requests, direct-origin traffic, bots or application analytics consent and script behaviour.

The comparison should identify which layer handled the traffic and whether the origin experienced the reported load. Use origin response metrics for origin health and browser metrics for real user experience where available.

A cached response may never appear as a new origin request, and an edge block can prevent a request from reaching hosting at all. JavaScript analytics can miss bots or visitors who block scripts, so its visitor count is not a direct substitute for access-log requests.

Not necessarily. Cloudflare may serve or block requests without forwarding them. Compare the origin-bound subset and the same measurement interval before drawing that conclusion.

• Reading Cloudflare security events for an incident
• Interpreting CF-Cache-Status during performance testing
• Diagnosing Cloudflare error 524 for a slow application request
• Diagnosing Cloudflare error 521 when the origin refuses connections

• Cloudflare: Zone Analytics
• Cloudflare: Origin Analytics