Cloudflare expands analytics history across every plan

More history for incidents discovered late

Cloudflare announced on October 2 that every plan now receives at least 30 days of analytics data. Adaptive datasets such as HTTP requests, security events and DNS analytics retain at least 31 days for Free and Pro domains, with queries covering up to 30 days at once. The update applies to the dashboard, custom dashboards and GraphQL API. It does not expand all dataset or field entitlements, and aggregated datasets keep existing plan limits.

The change addresses a familiar investigation problem: an incident is often recognized well after its first symptom. A short history can make a weekly review miss the relevant window. With a month available, operators can compare a suspicious period with previous weekdays and look for the point at which traffic behavior changed. That comparison is more useful than treating a single large number as evidence of an attack.

Source: Cloudflare official changelog

Analysis: Retention and forensic detail are different

A longer analytics window does not automatically become a full request archive. Aggregation, sampling and available fields influence which questions the data can answer. A chart can establish that error rates rose around a deployment without identifying every request or proving the deployment caused the errors. Teams should make those limitations visible in incident reports and use more detailed logs where the investigation requires individual events.

Consistent comparisons also matter. Changing filters, time zones or sampling assumptions between periods can create an apparent trend that reflects the query rather than the service. Save the query definition along with an exported result and record which dataset produced it. For security reviews, distinguish traffic that was blocked at the edge from traffic that reached an origin. A large blocked volume and a successful application compromise are separate findings requiring different evidence.

Turn the longer window into a repeatable review

Operations teams can use the additional history to establish ordinary weekday and weekend patterns before an incident occurs. Review request volume, errors, cache behavior and security events on a schedule that matches the business. Set expectations for seasonal changes or planned campaigns so an expected surge does not consume the same response effort as unexplained activity. A useful baseline should be simple enough that another operator can reproduce it.

Before relying on the new window, query the actual limits for the datasets used in monitoring. Confirm that automated reports handle a longer range without truncation or excessive cost, and that exports do not expose sensitive traffic details unnecessarily. The practical gain is not simply a larger chart. It is a better chance of recovering context when an alert arrives late, combined with a disciplined understanding of what analytics can show and what still requires another source of evidence.