We audited every free-tier quota on our Cloudflare account. Two were on fire.

Our Cloudflare account runs everything: five domains, twelve Workers, five Pages projects, four D1 databases, R2 buckets, queues. All of it on the free plan, all of it accumulated project by project over months, and none of it ever audited as a whole.

The setup

We run the account through cld-flare-maxxing, an open-source control center that snapshots the full account state, runs 61 heuristic checks against it, and refuses to change anything without a dry run and explicit approval. This audit started with one question: how much of the free tier have we actually used, and how bad is our shape?

What the audit measured

Not guesses. Live numbers for 23 quotas, pulled through Cloudflare's GraphQL analytics and REST APIs with a read-only token: requests per Worker, CPU percentiles, D1 rows read and written per day, R2 storage and operations, Pages builds, KV, queues, cache hit ratios per zone, plus the security findings from the check catalog.

Most of it came back comfortable. R2 at 0.12% of storage. KV literally unused. D1 storage at 0.07%. CDN traffic unmetered. Then two lines came back on fire.

Finding one: we had already blown a quota without knowing

Pages builds: roughly 691 used against the free plan's 500 per month. One project, our news site, burned 495 of those on its own.

The root cause was structural. A news site publishes articles constantly; every article was a git push; every push triggered a production build AND a preview build. Publishing was coupled to the build pipeline, so editorial volume translated directly into infrastructure burn.

Bonus discovery: the project's preview deployments were configured OFF. The API setting said "none". They built anyway. Cloudflare keeps a second field, a preview branch include list, and ours still said "all branches". When the two disagree, the wildcard wins. Dashboard saves write both fields consistently; raw API updates don't. That mismatch cost us roughly half the monthly build quota, silently.

Finding two: a Worker already past its ceiling

The free plan gives each Worker invocation 10ms of CPU. One of our Workers measured 17-45ms at the median and 675ms at P99. It worked only because traffic was low; under any real load, its requests start dying. That is not a quota you can wait out until the first of the month. It is an architecture problem with a countdown attached.

The decision: four options, honestly priced

1. Fix the preview config mismatch: free, minutes, halves the build burn.
2. Batch article publishing into 3-4 pushes a day: free, but adds hours of publish latency a news site does not want.
3. Decouple content from builds entirely (articles into D1, rendered by a Worker): the right long-term architecture, days of work.
4. Pay Cloudflare $5/month for Workers Paid: zero engineering, immediate.

We priced our own time against the subscription and took option 4. Here is what changed, per month, measured against what we actually use:

Both fires went out with one purchase. The blown build quota now sits at 14% used. The Worker that was failing its CPU budget at the median got 3,000x headroom. And the plan changes the failure mode itself: free tier quotas are hard stops (your stuff turns off), paid quotas are meters (traffic keeps serving, overage bills in cents per million).

$60 a year. The cheapest alternative that actually fixed both problems was days of refactor work. The value-for-money question answered itself.

The part nobody tells you: paid plans ship with zero alarms

Here is the uncomfortable trade in that "meters, not walls" model: Cloudflare has no spend cap. There is no "stop at $X" switch anywhere in the product. And after you upgrade, exactly zero usage notifications exist by default. A traffic spike, a buggy loop, or a scripted abuser can run your meter silently.

So the same afternoon, we built the closest thing to a hard limit that the platform actually supports, in layers:

• Usage alarm: a billing usage alert at 8M Workers requests, 80% of the included 10M, so overage is never a surprise. Plus an HTTP DDoS attack alert. Both email us. Both had to be created explicitly through the alerting API.
• Per-Worker CPU caps: every one of the twelve Workers now has an explicit CPU ceiling (500ms for most, more for the two that legitimately work hard), all set far above measured P99 but far below the plan's 30-second maximum. One runaway Worker can no longer drain the shared monthly CPU pool.
• Per-IP rate limits: the free plan includes one rate limiting rule per zone. Ours now block any single IP that exceeds 300 requests per 10 seconds. A human never hits it; a spam script hits it in the first second.
• Managed WAF: Cloudflare's free managed ruleset, deployed on all five zones. Exploit traffic dies at the edge before it reaches anything that bills.
• TLS baseline: SSL mode Full (Strict) on every zone (one was still on Flexible, meaning edge-to-origin traffic was plaintext), HSTS for a year with subdomains, DNSSEC enabled on the three zones that lacked it.

Every change ran the same way: a script prints a dry-run plan of exactly what will change, nothing mutates until a separate break-glass token and an explicit commit flag are both present, every attempt lands in an audit log, and every domain got verified live afterward. The riskiest change (SSL strict) went last, with an immediate check that all five sites still served.

Results

• Security findings: 30 before, 11 after, in one afternoon.
• Both quota fires out: builds at 14% of the new ceiling, CPU wall gone entirely.
• Four independent layers now stand between us and a surprise bill: WAF, rate limits, CPU caps, and usage alarms. That is the peace-of-mind part: not one magic switch, but enough layers that any runaway has to get through all of them silently, and the last layer's entire job is to not be silent.
• Total recurring cost: $5/month. Total engineering cost of the protections: one afternoon, and the scripts are reusable for any account.

Takeaways

1. Audit with live numbers, not vibes. We would have guessed "builds" last.
2. Quota problems come in three kinds: config debt (minutes to fix), architecture defects (days), and capacity trends (watch, don't act). Sort first; the fix type follows.
3. Sometimes $5 legitimately beats days of engineering. Price your own time honestly.
4. If a platform bills by the meter, your first act after upgrading should be building the alarms it didn't give you.
5. Check both fields. The preview-deployments-off-but-still-building mismatch is the kind of thing only an actual API read catches, and it was costing us half a quota.