Cloudflare API rate limit hit mid bulk-route update: 40 routes failed to map

TL;DR: Finish the 40 missing routes with a slow sequential resume, not a re-run. List the currently mapped routes to find exactly which ones never landed, wait out the rate-limit window, then apply only the missing ones one at a time with a short delay between calls. Diff the final route list against the intended mapping to prove all 40 are mapped. Make the update script idempotent so any future 429 is a resume, not a restart.

Cloudflare API rate limit hit mid bulk-route update: 40 routes failed to map

Steps

1. Stop the batch. List the routes currently mapped for the zone and worker. Expected: you can name exactly which of the 40 never landed.
2. Wait out the rate-limit window, honoring Retry-After. Expected: the next call returns 200.
3. Apply only the missing routes, one at a time, with a short pause between calls. Expected: each returns 200; no fresh 429s.
4. Diff the final route list against the intended mapping. Expected: empty diff - all 40 routes present and pointing at the right workers.
5. Save the intended mapping to a file and make the update script read it idempotently: re-running maps missing routes and skips existing ones. Expected: the next rate-limit stall resumes cleanly.

Use this when

• bulk route updates 429 partway with a known count of unmapped routes
• the route list shows some new routes and some missing ones
• "40 routes failed to map" or similar partial counts
• re-running the whole batch would duplicate work

Not for this skill when

• routes fail with validation errors - fix the route patterns, don't retry
• the failures are 401s - re-authenticate first
• routes map fine but traffic doesn't hit the worker - that's a routing/DNS question
• it's a single route - just retry it after a pause

Variant phrasings

• bulk route mapping hit 429 with routes unmapped
• route update batch partially failed on rate limits
• some worker routes missing after rate-limited update
• retrying only the failed route mappings

Why it happens

Route updates are individual API calls against the shared account budget, and a bulk update spends it fast. The first routes land, the budget runs out, and the rest fail - leaving a partially mapped zone. Re-running the whole batch from the top replays the successes and can burn the fresh budget before reaching the missing routes.

Edge cases

• Route patterns overlap. Two patterns matching the same hostname resolve by specificity - verify the intended winner actually won.
• Deleting a route and re-adding it is not the same as updating it. Prefer updates where the API supports them.
• The zone's route list is the source of truth, not the script's memory of what it sent.
• If another process edits routes concurrently, the end diff catches the interference.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_okig9Tw2d9gP0cLEiHmcuw