Operate from evidence and current limits

A successful deploy command is not evidence that your application works. It proves the upload finished. Users reach your app from their own networks, through DNS, TLS, cache, and bindings that all have to line up. So after every deploy, go look.

Limits and prices move

Platform limits and prices change over time. Free tiers grow, quotas shift, and a number you remember from last year may be wrong today.

When a design depends on a number, open the official docs page and check it that day. Then write the number down together with the page URL and the date. A design note that says “KV values up to 25 MiB, checked on developers.cloudflare.com/kv on 3 August 2026” is useful a year later. “KV can hold big values” is not.

What to record

For every deployed Worker or Pages project, keep these facts where you can find them: the compatibility date, the configuration file, the resource bindings, the deployment version that is live, and the exact rollback step.

Wrangler gives you the deployment history:

npx wrangler deployments list
# Created:     2026-08-03T08:14:22.000Z
# Author:      [email protected]
# Source:      Upload
# Message:     -
# Version(s):  (100%) 5800944a-2f1e-4c8b-9d3a-7e6f5a4b3c2d

That list is what turns “roll back” from a panic into a lookup.

Alert on what users feel

Put alerts on user-visible failure and on cost drivers. A spike in 5xx responses, a Worker error rate above zero, a queue backlog that keeps growing, a KV read count ten times your traffic. Those signals tell you something broke or something is about to get expensive.

The dashboard analytics show request counts, errors, and CPU time per Worker. Check them after each release, not only when someone complains.

The release record

Create a tiny release record every time you deploy:

commit: eb71b1e06
smoke test: GET /health returned 200
logs: no new application errors
rollback: previous deployment 5800944a2

Use real values from one practice release. Add the product limit or price that could stop the design, together with the official page and date you checked it. This makes a future review much more useful than “the deploy command succeeded.”

Four lines is enough. If the next release breaks, the previous record tells you what “working” looked like and which version to go back to.

Try this: write a release checklist for a practice project with a smoke test, a log check, a cost check, and one exact recovery action. Then run through it once on a deploy that changes nothing, so you know the checklist itself works.