Cloudflare D1 starts enforcing free-tier daily limits today

Cloudflare Developers changelog artwork.Cloudflare Developers
Cloudflare Developers changelog artwork.Cloudflare Developers
Tools & Apps

Cloudflare is now blocking D1 queries that exceed Workers Free daily row-read or row-write limits, with access returning at midnight UTC.

Cloudflare has started enforcing D1’s Workers Free daily row limits. From September 1, 2026, queries that push an account beyond its daily row-read or row-write allowance fail through both the Workers Binding API and the REST API. Access returns when the limit resets at midnight UTC; stored data is not affected.

What Cloudflare changed in D1

The enforcement is a behavior change, not a new dashboard warning. Cloudflare says accounts receive email alerts when they reach a limit, and the API returns explicit errors for exceeded row reads or writes. Developers can either wait for the next UTC day or move the workload to a paid Workers plan.

The affected unit is rows processed, not simply rows returned to the application. A query that returns one record can still consume a large allowance when it scans a broad table. That makes query shape, indexes, polling frequency, and dashboard fan-out relevant to the free-tier budget.

The failure mode developers should expect

An application can continue serving cached pages or static assets while D1-backed routes fail after the account crosses its daily threshold. A monitoring endpoint can also be the cause: repeated aggregate queries may consume more rows than the product traffic being measured.

Roazon documented that pattern after Cloudflare warned it about the September 1 enforcement date. Its account had read more than six million rows in one UTC day against a five-million-row allowance. The team traced the excess to a Grafana endpoint that rebuilt broad metrics on every refresh, then cut reads by polling less often, narrowing requests, caching responses, and making timestamp predicates indexable.

Practical checks before the next reset

Start with account-wide D1 analytics and rank statements by total rows read. Then inspect:

  • dashboard and health-check refresh intervals;
  • endpoints that fan one request into many aggregate queries;
  • time filters that wrap indexed columns in functions;
  • full-table scans that could use targeted indexes;
  • repeated identical responses that can be cached at the edge.

Cloudflare recommends reviewing query activity and adding indexes where they reduce unnecessary row reads. If optimization is not enough, the documented fallback is upgrading to Workers Paid rather than assuming the free allowance will stretch through the next UTC day.

The operational implication

Treat D1’s free tier as a hard daily budget. A row-limit failure can be temporary, but an unbounded metrics route or background poller will recreate it every day. Measure complete UTC days, keep a margin below the cap, and make the reset boundary explicit in incident handling.

Evidence

Cloudflare’s September 1 changelog is the primary source for the enforcement behavior and reset timing. Roazon’s independent production note corroborates the warning timeline and shows how monitoring queries can consume the allowance. No claim is made here about limits on paid Workers plans.

From reading to doing

Try the related loot

Put six hosted Workers AI models behind Cloudflare AI Search

Open loot