# Cloudflare extends analytics history to 30 days for Free and Pro plans

Free and Pro domains previously saw between 24 hours and 8 days of history depending on the dataset; Cloudflare now retains at least 31 days and allows 30-day queries in a single request, with domain analytics consolidated into one dashboard view.

Canonical URL: https://freelancenews.online/news/cloudflare-extends-analytics-history-to-30-days-for-free-and-pro-plans-182390f3
Published: 2026-10-02T13:17:39.173Z
Updated: 2026-10-02T13:17:39.173Z
Source published: 2026-10-02T00:00:00.000Z
Event date: Not established
Review status: source-reviewed
Review method: Automated comparison against retrieved source text; not independent fact-checking.

## Report

According to a changelog entry on its developer documentation site, Cloudflare has altered the amount of historical analytics data retained for each plan. At least 30 days of analytics data is now provided to every plan, the company states. Previously, depending on which dataset was queried, between 24 hours and 8 days of history could be seen by Free and Pro domains.

The retention change is described as applying to adaptive analytics datasets, a group Cloudflare names as including HTTP requests, security events and DNS analytics. For Free and Pro domains, those datasets now retain at least 31 days of data, and a single request can query up to 30 days at once. The distinction between retention and query window matters: the source describes both a storage period and a per-request limit, and they are not the same number.

The changelog frames the practical motivation in terms of investigation and comparison. A full month of history, it says, lets users look into an issue after it has happened, compare a given day against the same day in previous weeks, and distinguish a one-off spike from a longer-running trend. Those are the stated use cases; the source does not present measured outcomes or benchmarks for them.

The impact of this change extends beyond one surface alone. The same retention and query window is described, and it can be reached via the graphical interface as well as the programmatic interface developers rely on to pull analytics into their own tooling. Cloudflare says the new history is available in Custom Dashboards, through the GraphQL Analytics API, and in the Cloudflare dashboard.

Where domain analytics appear in the dashboard has also been reorganised by Cloudflare, alongside the retention change. Tabs that share one time range and one set of filters — Traffic, Performance, Security, Cache, Origin, DNS and Visitors — are now shown when selecting a domain and going to Analytics. Under Observability > Analytics, by contrast, account-level analytics sit. Rather than a change to the underlying data, this is a navigation and layout change.

Cloudflare is explicit that the change does not alter which datasets or fields a plan can access. Aggregated datasets, with httpRequests1hGroups given as the example, keep their existing per-plan limits. So the expansion applies to the adaptive datasets named in the changelog, not to every dataset a customer might query.

For anyone who needs to confirm the exact figures for a specific zone or account, the changelog points to querying the settings for each dataset. It also refers readers to plan-specific limits documented under Security Analytics, Security Events and the GraphQL Analytics API limits. In other words, the headline numbers — at least 31 days retained, up to 30 days per request — are described as a floor for the named adaptive datasets, with per-dataset detail available elsewhere.

The distinction between adaptive and aggregated datasets is the most important technical detail for developers building on this. A team that has built dashboards or alerting on httpRequests1hGroups should not assume the new window applies to that dataset, because the source says its per-plan limits are unchanged. Teams querying HTTP requests, security events or DNS analytics are the ones affected by the stated expansion.

For freelancers and small studios running client sites on Free or Pro plans, the change has a fairly direct operational consequence. Troubleshooting that previously had to happen within a day or so — or within a week for some datasets — can now draw on a month of history, which is enough to compare a problem against the same weekday in earlier weeks. That is editorial interpretation of the stated use cases, not a claim Cloudflare makes about outcomes.

There is also a workflow implication in the dashboard consolidation. Because the domain-level tabs now share a single time range and filter set, comparing traffic against security or cache data for the same period no longer requires re-establishing the window in each view. The source describes the shared range and filters as a fact of the new layout; it does not describe how the previous layout behaved in detail.

The API side deserves separate attention for anyone maintaining scripts. Because the changelog says the change applies through the GraphQL Analytics API, existing queries that request a window within the new limits should be able to return more history than before, subject to the per-dataset settings the source tells readers to check. The changelog does not describe any breaking change to query syntax or field availability.

What the source does not say is also worth noting. It gives no pricing information, no indication that any paid tier's retention changed, and no statement about datasets beyond the adaptive and aggregated categories it names. It does not claim the change was tested against particular workloads, and it offers no performance figures for querying the full 30-day window.

The changelog also does not specify an exact effective date in the extracted text. The source is a changelog post, and the retention and dashboard changes are presented as current rather than as a future rollout with a stated schedule. Readers who need to know precisely when a given zone received the new window should check the dataset settings the changelog points to.

For this audience — freelancers, designers and developers who often administer sites on lower-tier plans — the practical reading is straightforward. The ceiling on historical investigation has moved from hours or days to roughly a month for the named adaptive datasets, and the dashboard now presents domain analytics in one place with shared controls. Both are changes to what is available, not to what a plan is permitted to access.

The main caveat is scope. Because aggregated datasets keep their existing limits, and because the changelog directs readers to per-dataset settings for exact retention and query windows, anyone relying on this for compliance, incident review or client reporting should verify the specific dataset in question rather than assuming a uniform 30-day window across all analytics.

Taken together, the change is a retention and interface update rather than a new product. It expands how far back the named adaptive datasets go for Free and Pro domains, raises the single-request query window to 30 days, and tidies domain analytics into a tabbed view with one time range and one filter set. The unresolved questions are the per-dataset specifics and the exact timing, both of which the source defers to other documentation.

## Key points

- Free and Pro domains previously had between 24 hours and 8 days of analytics history depending on the dataset; Cloudflare now says every plan gets at least 30 days.
- Adaptive datasets — HTTP requests, security events and DNS analytics — retain at least 31 days for Free and Pro domains, with up to 30 days queryable in a single request.
- The change applies in the Cloudflare dashboard, Custom Dashboards and the GraphQL Analytics API.
- Aggregated datasets such as httpRequests1hGroups keep their existing per-plan limits, and the change does not alter which datasets or fields a plan can access.
- Domain analytics now appear as Traffic, Performance, Security, Cache, Origin, DNS and Visitors tabs sharing one time range and one filter set; account-level analytics are under Observability > Analytics.

## Practical implications — editorial interpretation

For freelancers and small teams administering Free or Pro domains, the named adaptive datasets now support roughly a month of retrospective investigation instead of hours or days, and the consolidated dashboard tabs let traffic, security, cache and DNS views share one time range and filter set. Developers pulling analytics through the GraphQL API should check per-dataset settings before assuming the wider window applies to every dataset they query, since aggregated datasets are explicitly unchanged.

## Limitations and unknowns

The extracted changelog text does not state an exact effective date, pricing, or whether any paid tier's retention changed. It gives no performance figures for querying the full 30-day window and no indication that the change was tested against particular workloads. Exact retention and query windows are deferred to per-dataset settings and to separate documentation on Security Analytics, Security Events and GraphQL Analytics API limits, which are not included in the supplied evidence.

## Sources

- [1] developers.cloudflare.com: Changelog
  https://developers.cloudflare.com/changelog/post/2026-10-02-30-days-analytics-on-every-plan/
  Retrieved: 2026-10-02T13:17:23.621Z

## Claim references

- Cloudflare says every plan now gets at least 30 days of analytics data. [source 1]
- Free and Pro domains previously saw between 24 hours and 8 days of history depending on the dataset. [source 1]
- Adaptive datasets including HTTP requests, security events and DNS analytics retain at least 31 days for Free and Pro domains, with up to 30 days queryable in one request. [source 1]
- The change applies in the Cloudflare dashboard, Custom Dashboards and the GraphQL Analytics API. [source 1]
- Aggregated datasets such as httpRequests1hGroups keep their existing per-plan limits, and the change does not alter which datasets or fields a plan can access. [source 1]
- Domain analytics now appear as tabs sharing one time range and one set of filters, while account-level analytics are under Observability > Analytics. [source 1]