Risk Scanner
$0Run it whenever you like. No signup.
Workers, Durable Objects, Queues and D1 have no hard spending cap. One loop can run all night. Scan your account for the patterns behind runaway bills, for free, on your own machine.
Sample data, not a real account.
Bars are drawn to scale.
Every finding shows the numbers behind it, what it would cost, and how to fix it.
Consumers retrying the same messages over and over, or set to retry many times with no dead letter queue.
The fix Keep max_retries low and add a dead_letter_queue, so failures stop and stay visible.
RUNAWAY
Messages are being retried over and over
email-queue
300,000 retries for 100,000 messages (3.00 per message)
Frequent jobs with heavy CPU, and runs creeping toward the 15-minute limit, where Cloudflare reports per-cron usage.
The fix Process a bounded batch per run, with a cursor saved between runs.
RUNAWAY
Cron work grows with your data
sync-worker (* * * * *)
CPU per run grew 3.0x across the window (10,000 to 30,000 ms)
Reads and writes that scan a whole table for a handful of rows. D1 bills every row scanned.
The fix Add an index on the columns in its WHERE clause, then check the plan with EXPLAIN QUERY PLAN.
WARNING
A query reads far more rows than it returns
prod-db
50,000 rows read for every row it returns
A reminder for every D1 database. Copies you keep elsewhere can't be seen from Cloudflare's API, so all of them are listed.
The fix Export it on a schedule to storage you control, and test a restore.
NOTE
No copy of this data outside Cloudflare
prod-db
2.50 GB stored, and no outside copy was reported
Cloudflare's analytics don't report alarms separately, so a usage scan can't tell an alarm loop from ordinary traffic. The report says so, instead of quietly showing zero.
What this scan could not measure
- Cloudflare's analytics don't report Durable Object alarms separately, so alarm loops can't be detected from usage yet.
$ npx knsept scan --demo
Watching, alerts and queue brakes all come with Guard Solo.
Guard reads your usage from outside your account every few minutes, with read-only access. It can see usage. It can't edit anything.
Set a budget per Worker, Durable Object, queue and database, and hear about it when one starts to run away.
Watch-only by default. Opt in and a Worker in your account pauses a runaway queue. Other resources get alerts until a brake is proven.
The CLI sends your token to Cloudflare's API and nowhere else. No signup and no telemetry.
Knsept will never hold a token that can change your apps. When brakes ship, the part that acts runs in your account, in code you can read.
Planned copies of your data go to storage you own. Knsept keeps only run records.
npx knsept scan, your token goes to Cloudflare and nowhere else. The web scanner passes it through once and throws it away.Run it whenever you like. No signup.
Daily budgets, email alerts and opt-in queue brakes for one account.
Everything in Solo, plus off-account copies and restore tests.
Sometimes. But you find out after the fact, and you may spend days waiting on a ticket. The point is not getting there.
You can. The hard part is the watcher: a kill switch inside your account shares that account's problems, and per-resource budgets take real work to keep accurate.
Good. Whole-account caps would still stop everything at once. Guard's brakes act on one resource at a time, starting with queues, so the rest of your app stays up.
No. It uses a read-only token and only reads usage and settings. It never runs a D1 query or opens your KV values or R2 files.
No. Knsept LLC is an independent company that builds tools for developers on Cloudflare.