WP Rocket preload is asynchronous. URLs are stored in the wp_wpr_rocket_cache table and move from pending to in-progress to completed or failed. When wp-cron is disabled, loopback requests fail, URLs redirect, private pages enter the queue, or another cache layer masks the result, the dashboard can look busy while no useful cache files are created. Repeatedly clicking clear and preload adds noise unless the queue state and cron path are inspected first.
Use this when preload never finishes, cache files do not appear, URLs remain pending or in-progress, many rows fail, or a large site repeatedly rebuilds the same small set of pages.
Quick answer
Check the preload table state distribution, the next scheduled WP Rocket preload event, wp-cron health, loopback access, redirects, authentication, and cache directory behavior. Pick one public 200 URL and follow it from queue row to origin request to cache file. Fix the first broken transition, then clear and preload once. Do not delete the whole queue until you have preserved the failed status and reason.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Pending | Old row with no worker | Cron dispatch resumes |
| In progress | Row exceeds normal duration | Worker completes or records failure |
| Redirect | Old URL to canonical | Destination completes |
| Private URL | Auth or maintenance page | Excluded from preload |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Measure queue state and age | Record counts and oldest timestamps for pending, in-progress, completed, and failed rows in the WP Rocket preload table. | Pending and in-progress rows advance within the expected processing window. |
| Verify cron dispatch | Confirm wp-cron runs through the site traffic path or a real server cron and that the expected WP Rocket preload hooks have future timestamps. | The canary URL returns 200 without authentication, challenge, or unintended redirect. |
| Trace one public canary URL | Test one queued URL for public 200 access, redirects, authentication, WAF challenge, robots behavior, canonical destination, and origin response time. | Cache output and headers match the active hosting architecture. |
| Correct access, redirect, or worker failure | Inspect the WP Rocket cache directory and hosting cache behavior, noting that some managed hosts use a different page-cache layer. | A second preload does not create a growing duplicate or failed queue. |
What to check first
- Record counts and oldest timestamps for pending, in-progress, completed, and failed rows in the WP Rocket preload table.
- Confirm wp-cron runs through the site traffic path or a real server cron and that the expected WP Rocket preload hooks have future timestamps.
- Test one queued URL for public 200 access, redirects, authentication, WAF challenge, robots behavior, canonical destination, and origin response time.
- Inspect the WP Rocket cache directory and hosting cache behavior, noting that some managed hosts use a different page-cache layer.
- After correcting the first blocked transition, start one clean preload and measure queue movement, cache files, error logs, CPU, and completion time.
Field notes
- Write the expected result before changing anything and keep one repeatable canary fixture for the full test window.
- Record exact versions and UTC timestamps because cache purges, retries, scheduled actions, and deployments can change the evidence between tests.
- Test the public browser path and the server-side result, not only an admin preview or isolated API response.
- Close the task only after the visible workflow, stored record, logs, and relevant downstream system agree.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp cron event list | grep -E 'rocket|preload'
wp db query "SELECT status, COUNT(*) total, MIN(modified) oldest FROM wp_wpr_rocket_cache GROUP BY status;"
curl -sS -I https://example.com/canary-page/
find wp-content/cache/wp-rocket -type f -mmin -10 | head
Why this usually happens
- WP-Cron is disabled without a working system cron replacement.
- A loopback, WAF, or basic-auth rule prevents the worker from requesting the queued URL.
- Redirecting source URLs are judged as failed even when the final destination can be cached.
- A managed host serves its own cache, so the expected WP Rocket disk folder is not the right success signal.
Decision rule
A preload is healthy when queue states continue moving and a named public canary produces the expected cached response. A spinning dashboard or one cache file is not sufficient evidence.
Production verification checklist
- Pending and in-progress rows advance within the expected processing window.
- The canary URL returns 200 without authentication, challenge, or unintended redirect.
- Cache output and headers match the active hosting architecture.
- A second preload does not create a growing duplicate or failed queue.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Measure queue state and age
- Verify cron dispatch
- Trace one public canary URL
- Correct access, redirect, or worker failure
- Run one clean preload and observe completion
Mistakes to avoid
- Changing production code, cache settings, form fields, webhook endpoints, or firewall rules before preserving the exact failure, current versions, and rollback point.
- Treating one successful page load or dashboard status as proof while browser behavior, PHP logs, scheduled jobs, delivery records, and downstream data remain unchecked.
- Testing a different role, device, locale, form, URL, order state, cache state, or plugin combination than the workflow that users actually reach.
- Leaving helper plugins, debug logging, copied secrets, broad exclusions, temporary endpoints, or test notifications active after the verification window.
Questions teams ask during testing
Can I run this directly on production?
Begin with read-only checks and preserve evidence. Use staging for changes that affect PHP, cache generation, form submission, payment, email, or customer state. When production is necessary, use one named canary, a short monitored window, and a tested rollback.
How do I avoid a false positive?
Match the exact plugin and WordPress versions, URL, role, device, locale, cache state, and integration path. Repeat the same fixture before and after the change, then compare stored evidence rather than relying on memory.
What evidence should I keep?
Keep UTC time, versions, affected URL or record ID, expected result, actual result, relevant log lines, configuration snapshot, change made, rollback point, and final verification. Remove credentials, payment details, and personal data.
When should I bring in a specialist?
Escalate when the site is unavailable, checkout or lead capture is affected, a security boundary is unclear, several systems disagree, or the next step could destroy evidence. A concise incident packet makes outside help much faster.
What to tell the client or owner
Give the owner a short evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected and actual result, key logs, the change made, rollback point, final result, owner, and next review date. Redact credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP repair the stuck WP Rocket preload queue.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references