Skip to content
Latchkey

Cloudflare purge cache 429 rate limit (code 10035) in CI

Cloudflare throttled the purge: a 429 means you exceeded the cache-purge rate limit (1000 purge API calls per 300 seconds per zone). Retrying immediately keeps hitting the wall; back off instead.

What this error means

The purge_cache call returns HTTP 429 with error code 10035 and a message about too many requests. It appears when a matrix or many parallel jobs purge the same zone at once.

Cloudflare API
{
  "success": false,
  "errors": [
    { "code": 10035, "message": "More than 1000 requests per 300 seconds reached. Please wait and consider throttling your request speed" }
  ]
}

Common causes

Many parallel jobs purge the same zone

A build matrix or fan-out of deploy jobs each call purge_cache, and together they cross the per-zone limit within the 300 second window.

Per-URL purges in a tight loop

Purging thousands of individual files one request at a time quickly exhausts the 1000-call budget.

How to fix it

Purge once per deploy and batch URLs

  1. Run a single purge step after the deploy completes, not per job.
  2. Batch up to the API maximum of 30 files per purge request instead of one per call.
  3. Prefer purge_everything or tag/prefix purges over thousands of single-file calls.
Terminal
# up to 30 files in one request instead of 30 requests
curl -sS -X POST \
  "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/purge_cache" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/a.js","https://example.com/b.css"]}'

Back off and retry on 429

Treat 429 as retryable with a delay rather than failing the job immediately.

Terminal
for i in 1 2 3; do
  code=$(curl -s -o /dev/null -w '%{http_code}' -X POST "$PURGE_URL" \
    -H "Authorization: Bearer ${CF_API_TOKEN}" -H "Content-Type: application/json" \
    --data '{"purge_everything":true}')
  [ "$code" = "200" ] && break
  echo "purge returned $code, backing off"; sleep $((i*10))
done

How to prevent it

  • Consolidate purges into one step per deploy.
  • Batch files (max 30 per request) instead of one call per file.
  • Add exponential backoff so a transient 429 does not fail the job.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →