Wordfence runs a scan as a series of stages and loopback requests. When a scan pauses, retries, or dies, the visible stage is useful but may not identify the constrained resource. PHP memory, max execution time, worker exhaustion, database locks, disk I/O, inode limits, CPU throttling, DNS, IPv6, TLS, WAF rules, cron overlap, backups, and malware signatures can all produce similar symptoms. Increasing one global timeout can make the failure slower and harder to observe.
Use this when Wordfence scans fail repeatedly at a stage, only fail during busy periods, pass with low-resource mode, or disagree across sites on the same host.
Quick answer
Record Wordfence version, scan type, stage transitions, resume attempts, loopback request IDs, and exact UTC failure time. Export host CPU, memory, swap, PHP workers, slow requests, database load, disk latency, quota, cron, backup, firewall, DNS, and network evidence for the same window. Plot stage and resource events on one timeline. Change one owned variable, such as stage execution time, low-resource mode, IPv4-only mode, cron overlap, or worker capacity, and repeat the same scan fixture. Keep the change only when the evidence and completion rate improve.
What to check first
- Capture scan ID, type, options, start and stop times, last stage, resume count, error text, site size, file count, and the previous successful scan.
- Export CPU, memory, swap, process limits, PHP-FPM workers, PHP errors, database connections, slow queries, disk latency, quota, and host throttling for the same UTC window.
- Join Wordfence loopback, cron, REST, AJAX, WAF, CDN, DNS, TLS, IPv4, IPv6, and origin access events by request ID and timestamp.
- Mark overlapping backups, malware scans, imports, cache preloads, deployments, reports, and traffic spikes instead of testing during an unknown workload.
- Change one setting per run and compare stage duration, retries, resource peaks, scan completeness, and impact on public requests.
Why this usually happens
- The last visible stage is blamed although the next loopback request never starts.
- Host dashboards average metrics and hide short PHP-worker, memory, or I/O saturation.
- A backup or scheduled import overlaps the scan only on certain days.
- Several settings change together, so a successful rerun cannot identify which change mattered.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
utc_time,scan_id,stage,resume,cpu_pct,memory_mb,php_busy,db_conn,disk_ms,http_status
2026-08-31T02:10:00Z,scn_441,file_changes,1,92,1510,8,47,38,200
2026-08-31T02:10:30Z,scn_441,malware,2,99,1802,10,62,91,504
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Freeze one repeatable scan fixture | Capture scan ID, type, options, start and stop times, last stage, resume count, error text, site size, file count, and the previous successful scan. | The same scan completes repeatedly with stage and loopback evidence intact. |
| Join stage and host telemetry | Export CPU, memory, swap, process limits, PHP-FPM workers, PHP errors, database connections, slow queries, disk latency, quota, and host throttling for the same UTC window. | CPU, memory, workers, database, disk, and network stay within documented budgets. |
| Remove scheduled workload overlap | Join Wordfence loopback, cron, REST, AJAX, WAF, CDN, DNS, TLS, IPv4, IPv6, and origin access events by request ID and timestamp. | Public requests do not gain errors or unacceptable latency during the scan. |
| Change one owned limit or route | Mark overlapping backups, malware scans, imports, cache preloads, deployments, reports, and traffic spikes instead of testing during an unknown workload. | Temporary IPv4, low-resource, exclusion, and timeout changes have owners and review dates. |
Decision rule
Keep a tuning change only when it explains the observed constraint, improves repeated scan completion, and does not degrade public requests or hide an infrastructure fault.
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 |
|---|
| Normal scan | Typical workload | Baseline stage and resource graph |
| Low-resource | Same files and time | Lower peaks, longer duration |
| IPv4-only | Proven IPv6 issue | Loopbacks complete |
| Cron isolated | No backup overlap | Causal overlap confirmed or ruled out |
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.
- Freeze one repeatable scan fixture
- Join stage and host telemetry
- Remove scheduled workload overlap
- Change one owned limit or route
- Verify completion and public impact
Production verification checklist
- The same scan completes repeatedly with stage and loopback evidence intact.
- CPU, memory, workers, database, disk, and network stay within documented budgets.
- Public requests do not gain errors or unacceptable latency during the scan.
- Temporary IPv4, low-resource, exclusion, and timeout changes have owners and review dates.
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, URL, role, request, UTC time, fixture, and rollback point.
- Treating one successful browser view as proof while logs, stored records, background jobs, caches, and downstream systems remain unchecked.
- Testing a different role, locale, cache state, form, order, device, or integration path from the one users actually reach.
- Leaving debug output, temporary exclusions, test accounts, broad permissions, helper code, or relaxed firewall rules active after verification.
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 diagnose Wordfence scan failures.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references