Hard one. The platform gap is real — CPU-time monitoring is a relic from before Workers grew DO/KV/D1 with their own metered ops, and per-binding spend caps would have caught this.

A different angle worth mentioning: KV + edge cache instead of DO + alarms. My share-link backend uses a sliding TTL (re-put on every cache miss). The key property is that caches.default with Cache-Control: max-age=3600 becomes a natural throttle — at most 24 cache misses per day per key, so KV writes are bounded by (keys × 24) regardless of traffic. A scraper hammering one share link costs ~24 writes/day, not millions.

No alarms means no self-triggering loop is even possible. Writes only happen on inbound requests, which are themselves rate-limited by WAF.

Trade-off: no strong consistency, no per-instance state. For a stateless redirect service that's fine; for an agent runtime it isn't.

What I'd actually want from Cloudflare: a per-binding hard spend cap, default-on for new accounts, with explicit opt-in to raise. "Guardrails off by default" feels especially weird during Agents Week.

$34k in 8 days with zero users is the flavor of bug that makes CFOs distrust engineering. The thing that would have caught this: anomaly detection scoped to the service + the account, not just the total bill. Most teams monitor the aggregate and only spike-alert above some threshold — by then it's 4 days old. Per-service p95-vs-median alerts at hourly granularity would have flagged this inside 6 hours. Cloudflare should absolutely ship platform-side guardrails here, but until they do, self-built alerts at the service level are the only real defense.

>I'm a pre-launch sole proprietor who put all my personal savings into this startup. This bill would financially destroy me for usage that generated zero business value.

That's terrifying.

If I'm not mistaken even AWS tends to forgive instances like this, so here's hoping Cloudflare has a similar disposition.

Good luck!

[dead]

god that's hilarious

you're an absolute L in their P&L this month