Wordfence splits scanning into stages and may resume work across requests. When one stage times out, loses its runner, collides with another process, or cannot make a self-request, the scan can appear to restart or consume repeated resume attempts. Raising every PHP and scan limit can make the symptom less frequent while leaving a cron, loopback, database-lock, filesystem, or host policy problem untouched. The useful evidence is a timeline of stage start, progress, stop reason, resume request, resource state, and next runner.
Use this when Wordfence scans stall at a repeatable percentage, show resume-attempt messages, finish only from the manual page, or fail differently between scheduled and on-demand scans.
Quick answer
Record the Wordfence version, scan type, stage, percentage, UTC timestamps, resource values, and the exact final log lines. Check Wordfence diagnostics, WP-Cron or server cron, loopback requests, outbound HTTP, database locks, disk I/O, memory, execution time, and overlapping security or backup jobs. Reproduce with standard and low-resource scan options on one canary. Change one owned limit or runner condition at a time, then require both a manual and the next scheduled scan to complete.
What to check first
- Export Wordfence scan logs with stage names, progress, resume count, request IDs, stop reasons, UTC times, and whether the run was manual or scheduled.
- Record PHP memory and time limits, Wordfence resource mode, hosting process limits, disk space, I/O pressure, database health, and concurrent backup or malware jobs.
- Verify WP-Cron or the replacement server cron, loopback response, canonical DNS, TLS, IPv4 and IPv6 routes, WAF action, and authentication cookies.
- Run one canary with the normal profile and one with a documented lower-resource profile, changing only one variable between attempts.
- After the owned cause is repaired, complete a manual scan and the next scheduled scan while watching logs and resource baselines.
Why this usually happens
- WP-Cron is disabled without a reliable server-level replacement.
- A loopback request receives a WAF challenge, redirect loop, TLS failure, or IPv6 timeout.
- One expensive file, database, or signature stage repeatedly crosses a process limit.
- Backup, optimization, malware, and scan jobs overlap and compete for the same resources.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp cron test
wp cron event list --fields=hook,next_run_gmt,next_run_relative | head -n 60
wp option get cron | head -c 2000
# Join these times to Wordfence scan stages, PHP logs, and hosting resource graphs.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Capture the exact failing stage | Export Wordfence scan logs with stage names, progress, resume count, request IDs, stop reasons, UTC times, and whether the run was manual or scheduled. | The failing stage and its original stop reason are documented. |
| Audit cron, loopback, locks, and resources | Record PHP memory and time limits, Wordfence resource mode, hosting process limits, disk space, I/O pressure, database health, and concurrent backup or malware jobs. | Cron and loopback run without challenge, redirect, TLS, route, or authentication failure. |
| Reproduce with one-variable canaries | Verify WP-Cron or the replacement server cron, loopback response, canonical DNS, TLS, IPv4 and IPv6 routes, WAF action, and authentication cookies. | No overlapping job or resource limit interrupts the canary. |
| Repair the owned runner or limit | Run one canary with the normal profile and one with a documented lower-resource profile, changing only one variable between attempts. | The next scheduled scan completes with a normal resume count and clean logs. |
Decision rule
Do not approve a timeout increase by itself. The same scan profile must complete manually and on schedule without exhausting resume attempts or causing new site errors.
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 |
|---|
| Manual scan | Admin starts the same profile | All stages complete |
| Scheduled scan | Cron starts without visit | All stages complete |
| Low-resource canary | Reduced load profile | Identifies capacity sensitivity |
| Overlap window | Backup job active | No lock or timeout collision |
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.
- Capture the exact failing stage
- Audit cron, loopback, locks, and resources
- Reproduce with one-variable canaries
- Repair the owned runner or limit
- Pass manual and scheduled scans
Production verification checklist
- The failing stage and its original stop reason are documented.
- Cron and loopback run without challenge, redirect, TLS, route, or authentication failure.
- No overlapping job or resource limit interrupts the canary.
- The next scheduled scan completes with a normal resume count and clean logs.
What to tell the client or owner
Give the owner a concise evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key logs, change made, rollback point, final result, owner, and next review date. Remove credentials and personal data before sharing it.
Mistakes to avoid
- Changing production before recording the exact version, request, UTC time, fixture, and rollback point.
- Treating one successful browser view as proof while logs, stored records, background jobs, and downstream systems remain unchecked.
- Testing a different role, cache state, locale, form, order, device, or integration path from the one users actually reach.
- Leaving debug output, temporary exclusions, test accounts, broad permissions, or helper code active after the verification window.
Questions teams ask during testing
Should I test this directly in production?
Start with read-only evidence and reproduce on staging when the change affects code, security, checkout, forms, indexing, or permissions. If production is required, use one named canary, a short monitored window, and a tested rollback.
How do I avoid a false positive?
Repeat the same fixture with the same versions, URL, role, locale, cache state, and downstream integration. Compare stored evidence and logs instead of relying on a visual impression.
What evidence should I keep?
Keep UTC time, exact versions, URL or record ID, expected result, actual result, relevant log lines, change made, rollback point, owner, and final verification. Redact credentials and personal data.
When should I escalate?
Escalate when the site is unavailable, security scope is unclear, checkout or lead capture is affected, several systems disagree, or the next action could destroy evidence.
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 Wordfence scan runner.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references