Troubleshooting

Diagnose the problems people actually hit: nothing runs, everything errors, or warming works but nothing gets faster.

12 min read

Problems fall into three groups, and identifying which one you have narrows the cause immediately.

Nothing runs at all

No crawl data appears. Usually verification or the Active switch.

It runs but errors

URLs return 403, 429, 5xx, or redirects. Usually blocking or wrong URLs.

It runs cleanly but nothing improves

Status codes are fine, load times are not. Almost always a caching problem, not a warming one.

Nothing runs at all

  1. 1

    Is the warmer Active?

    The most common cause by a wide margin. An inactive warmer keeps its settings and never runs.

  2. 2

    Is the hostname Verified?

    Check Account → Hostnames. Pending verification blocks every run. See Hostname verification.

  3. 3

    Does the entry URL hostname exactly match the verified one?

    example.com and www.example.com are different. A warmer pointed at the unverified form will not run.

  4. 4

    Have you hit a plan limit?

    Check Account → Subscription. Exhausting a daily or monthly URL budget stops warming until the period resets.

  5. 5

    Is a schedule window blocking it?

    If a warm schedule is set, scheduled starts outside the window are skipped. Try starting the warmer by hand — if that works, the window is the cause.

  6. 6

    Are you in the right workspace?

    Warmers belong to a workspace. Check the sidebar selector — the warmer may exist somewhere you are not currently looking.

It runs but URLs error

403 Forbidden

Something is deliberately blocking the crawler — a WAF, a bot filter, Cloudflare bot management, or a security plugin.

  • Allow-list Cache Rocket's requests at your firewall or CDN.
  • Set a distinctive custom user agent and allow-list that.
  • Lower max URLs per minute — many bot filters trigger on request rate rather than identity.
  • Check for a country block, if your warmer's region differs from where you usually browse from.

429 Too Many Requests

You are warming faster than your server or CDN permits. Lower max URLs per minute substantially — halve it, confirm the errors stop, then raise gradually. If your host enforces a documented rate limit, stay comfortably under it.

5xx server errors

Your origin is failing under the load. Lower the rate limit immediately.

Treat 5xx as urgent

If warming can push your origin into server errors, so can a modest traffic spike. The warmer has found a real capacity problem. Reduce the rate now, then look at why the origin is that fragile.

301 / 302 redirects

Your entry URLs or internal links point somewhere that redirects. Every redirect wastes a request and warms the wrong address.

  • Use the final destination as your entry URL, including or excluding www as your site actually serves it.
  • Always use https://, never http://.
  • Enable Rewrite to HTTPS if internal links still use http.
  • Match your site's trailing-slash convention.

404 Not Found

Broken internal links, a stale sitemap listing removed pages, or discovered URLs that were never real. Fix the links, regenerate the sitemap, or exclude the offending pattern.

Wrong number of URLs

Far fewer than expected

  • Depth is too low. Pages further than your depth setting are never reached.
  • Sitemaps are off. Turning them on is usually the single biggest coverage win.
  • Exclusions are too broad. A rule intended for /search may be catching more than you meant.
  • Your navigation is JavaScript-only. Links that do not exist in the HTML cannot be discovered by an HTTP fetch. Consider browser warming, or add sitemaps.

Far more than expected

  • Faceted URLs. Filter and sort combinations multiply without limit. Exclude them, using regex if available.
  • Session or tracking parameters. URLs differing only by a query parameter are counted separately.
  • Deep pagination. Archive pages twenty deep are rarely worth warming.
  • Depth is too high. Step it back one level.

Tip

Unexpectedly high URL counts are the most common way to burn a monthly budget on pages nobody visits. When the count surprises you, look at the actual URL list before raising your plan.

It runs cleanly but nothing gets faster

Status codes are 200, URLs are covered, and both load times are still slow. Warming is working — your caching is not. Cache Rocket can only refill a cache that exists.

  1. 1

    Confirm the page is cacheable

    Look at the response headers. Cache-Control: no-store or private means it will never be cached, no matter how often you warm it.

  2. 2

    Check for Set-Cookie on public pages

    Many caches refuse to store a response that sets a cookie. Analytics and session cookies on anonymous pages are a frequent culprit.

  3. 3

    Check your CDN's cache rules

    Confirm the path is actually cached rather than bypassed, and see what the cache key varies on.

  4. 4

    Compare the warmer's request to a real one

    If the warmer sends a cookie, header, or user agent that visitors do not, it may be filling a cache variant nobody requests.

  5. 5

    Look at Cache health's cold URL list

    It identifies exactly which URLs are affected, which usually reveals the pattern. See Cache health.

The most useful diagnostic

Request the same URL twice yourself with curl and compare timings and cache headers. If your own second request is not faster either, the problem is definitively in your caching setup rather than in Cache Rocket.

Check timing and cache headers by hand
bash
curl -s -o /dev/null -w "%{time_total}s\n" https://www.example.com/
curl -s -o /dev/null -w "%{time_total}s\n" https://www.example.com/

curl -sI https://www.example.com/ | grep -i "cache\|age\|set-cookie"

Integration problems

A deploy webhook returns 401.
API keys are wrong, expired, or superseded. Confirm the header names are exactly X-Public-Key and X-Secret-Key, and check for truncated values. See API keys.
A deploy webhook succeeds but nothing warms.
The hostname in the body does not match an active warmer. Check the exact hostname including www, and that the warmer is Active.
A CDN purge is rejected.
The token lacks purge permission or is paired with the wrong zone ID. See CDN integrations.
The WordPress plugin says the keys are invalid.
Re-copy both keys, watching for whitespace. If a newer pair has been generated since, the old one no longer works.
Alerts never arrive.
Test the webhook URL directly with curl. Confirm at least one event is selected, and that the Slack or Discord integration still exists.

Still stuck?

Gather these before contacting support — it turns a long exchange into a single reply:

  • The warmer name and the hostname involved.
  • What you expected, and what actually happened.
  • Representative status codes and load times from the warmer's results page.
  • Whether the hostname shows Verified.
  • Your plan name, and your subscription ID from the References section of the subscription page.