Key details

  1. Cloudflare announced the change October 2, 2026.
  2. Adaptive HTTP, security and DNS datasets retain at least 31 days on every plan.
  3. Free and Pro plans previously had 24-hour to eight-day history for some datasets.
  4. Up to 30 days can be queried in one request through dashboards or GraphQL.
  5. Aggregated datasets and field availability retain separate plan-specific restrictions.

What builders should take away

  1. Revisit dashboards or scripts previously capped at one or seven days and test a 30-day window.
  2. Use a monthly baseline to distinguish one-off bot spikes from persistent traffic changes.
  3. Check each GraphQL dataset's settings and node limits before promising a uniform 31-day history.
  4. Do not treat this change as raw request-log storage or as expanded access to Enterprise-only datasets.

What changed

On October 2, 2026, Cloudflare increased retention for adaptive analytics datasets, including HTTP requests, security events and DNS analytics, to at least 31 days on every plan. Free and Pro domains previously had as little as 24 hours or up to eight days depending on the dataset. Customers can now query up to 30 days in a single request through the Cloudflare dashboard, Custom Dashboards and GraphQL Analytics API. Domain analytics are consolidated into Traffic, Performance, Security, Cache, Origin, DNS and Visitors tabs sharing one time range. This does not add previously unavailable fields or datasets to a plan; aggregated datasets such as httpRequests1hGroups retain their own plan-specific limits.

Why it matters

Longer retention changes what solo operators and small SaaS teams can investigate without buying higher-tier analytics. A traffic spike, attack burst or DNS anomaly can now be compared with previous weeks instead of disappearing from the free-tier window. The practical distinction is adaptive dataset access: teams that automate reports through GraphQL must still check node-specific limits rather than assume every dataset has a 31-day history. This is separate from Cloudflare's recently expanded Logpush export service, covered in BTN draft #425.

From hours or days to a useful monthly window

Cloudflare says Free and Pro accounts previously saw 24 hours to eight days for some adaptive analytics datasets. The new minimum 31-day retention supports one 30-day query interval and comparisons with the same weekday in prior weeks.

Dashboard and API access both change

The expanded window applies to domain dashboards, Custom Dashboards and GraphQL Analytics API. Cloudflare has also grouped domain analytics views under one shared date filter to make comparisons across HTTP, security, cache and DNS easier.

The word adaptive matters

The retention guarantee applies to adaptive datasets such as httpRequestsAdaptiveGroups and firewallEventsAdaptive. Aggregated nodes such as httpRequests1hGroups still have plan-specific history and query constraints. Other field entitlements remain unchanged.

This is not raw log retention

Aggregated or sampled analytics are not the same as per-request raw logs. Cloudflare's separate Logpush pricing and included allowances determine the economics of exporting raw records; that is a different service and decision.

What to watch next

  • Whether Cloudflare extends similar windows to currently restricted aggregated datasets.
  • Any changes to GraphQL query cost or rate limits as larger windows are used.
  • How historical dashboard data behaves for zones newly eligible for the expanded window.

Still unclear

  • Cloudflare does not say every analytics dataset or field now has 31-day retention.
  • The precise maximum lookback and query interval remain node- and plan-dependent.
  • No independent benchmark is available for the performance of long-window GraphQL queries on very high-traffic zones.

Sources

Direct reading behind this dossier.

2 sources
GraphQL Analytics API limits
Cloudflare Developers primary documentation

Confirms 31-day adaptive retention and separate aggregated node limits.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment