Is a Wordfence Scan Slowing Down Your Server?

Sites on one of our servers slowed to a crawl while our monitoring insisted everything was fine. The cause was not any one website. It was two dozen Wordfence malware scans all running at the same moment. Here is how we found it and what we did about it.

This is a write-up of a real problem on one of our own hosting servers, published because we think other hosts and server admins will run into the same thing and spend a day chasing the wrong cause. We did.

First, the fair part, because it matters: Wordfence is a good plugin. Its firewall and its login protection do real work, and we are not telling anyone to uninstall it. The problem we hit is narrower and more specific than that. It is what happens when a lot of WordPress sites share one server and every one of them runs its own malware scan on its own schedule, with nobody able to choose when.

The Symptom: Monitoring Said Healthy, Visitors Said Slow

Pages on the affected server took 7 to 40 or more seconds to load if they were not already cached. The WordPress login page took 4 to 5 seconds, every single time.

Our uptime monitoring said everything was healthy, and it was not lying. A monitoring check fetches a page the same way an anonymous visitor does, so it gets the cached copy, and the cached copy still came back in under a second. The slowdown only hit two groups: pages that had to be built fresh, and logged-in users, who never get served a cached page at all.

What We Measured on the Server

Before blaming anything we took readings from inside one of the affected sites and from the server itself.

Measured on a 6-core cPanel/WHM server running CloudLinux and LiteSpeed, 2026-10-14. A load average of 28 on 6 cores is roughly 4.7 times what the machine can actually process.

That last row is the important one. The database was fine. The object cache was fine. The pages were not bloated. This was not a slow website. It was a starved server. A simple timed loop inside PHP showed the site spending 88 to 91% of its time doing nothing but waiting for a slice of CPU.

Found It: Every Account Running the Same Process at Once

WHM’s Process Manager gave it away immediately. Nearly every hosting account on the server had the same process running at that moment, admin-ajax.php, each one consuming around 18 to 20% of a CPU core. Twenty-some accounts doing that at the same time adds up to more CPU than the server has.

The site’s own access log named the culprit:

POST /wp-admin/admin-ajax.php?action=wordfence_doScan

That is Wordfence’s malware scan. On the site we looked at, the scan had been running for over an hour and was working through files at less than one file per second, because there was no CPU left for it to use.

Why a Wordfence Scan Ends Up Slowing Down a Whole Server

There are four things stacking up here, and only one of them is really about Wordfence.

• A malware scan is genuinely heavy work. It reads and checks thousands of files per site and compares them against signatures. Wordfence says as much in its own tuning guide: scans “read many files and use CPU time”. That is not a flaw, it is what scanning is.
• A scan is not one request, it is a chain of them. It runs for a time budget, then starts a fresh background request to pick up where it left off, over and over until it finishes. Wordfence’s code caps that budget at 45 seconds: it takes half of your PHP time limit, but clamps the limit to 90 seconds first, so once your PHP limit is above 90 the budget stops changing no matter how high you set it.
• In our case they did not give way after 45 seconds. We sat and watched individual scan processes stay in the run queue for five minutes and more, holding CPU and not exiting. We cannot tell you why, and we did not stop to find out with the server on its knees. We are reporting what we saw, which is not what the documented behaviour says should happen.
• Each site scans entirely on its own. A WordPress site has no idea it is sharing a machine with thirty others, and Wordfence running inside it has no way of knowing that thirty other copies of itself are mid-scan right now.
• On the free version you cannot choose when it runs. Wordfence’s documentation is clear that scheduling is a paid feature: “Premium license key customers can adjust how often the scan runs.” Free sites get a quick scan daily and a full scan every 72 hours, on Wordfence’s timing, not yours. Premium customers can pick start times for each day, and Wordfence lists that as one of the benefits of paying.

Put those together and on a shared server you get an unavoidable, unschedulable, CPU-hungry job firing on dozens of sites independently. Sooner or later they land on top of each other.

Wordfence Knows About This, and Says So

We want to be fair here, because Wordfence does not hide from this problem. Their own scheduling documentation addresses it directly on two fronts.

They randomise start times, stating that every scan runs within an hour of its scheduled time to prevent “a large amount of scans from starting at the exact same time.” And they acknowledge the queueing that happens anyway: scheduled scans “may be delayed if other sites’ scans are running at the same time on your server,” typically by half an hour or less, with a priority lane that guarantees paid scans go ahead of free ones.

Both of those are sensible mitigations. Neither of them is a cap on how many scans can run concurrently on one machine, which is the thing that actually bit us. A 30-minute spread does not help when a single scan is taking well over an hour because the CPU is already gone.

Wordfence also gives the honest answer in its resource-tuning guide, which is worth quoting because it is their recommendation and not ours: if you want to reduce periodic resource usage, “consider disabling automatic scans and running manual scans” after updates or when you suspect a problem. That is exactly what we did.

The Other Half of the Problem: Two Scanners Doing One Job

There is a second reason this was wasted effort on our particular server, and it is probably true of yours as well.

Our servers already run Imunify360, which includes the ImunifyAV malware scanner and operates at the server level rather than inside each site. Imunify is explicit that coverage is not per-site: “all hosting accounts are covered in any case as Imunify360 works server-wide.” It scans every account from one place, on one schedule the administrator controls.

So every Wordfence scan on that server was re-reading files that had already been scanned, less efficiently, one site at a time, at a moment nobody had chosen. Two malware scanners is not twice the protection. It is one lot of protection and two lots of CPU.

The Fix on a Single Site

If you run one WordPress site and your host already scans for malware at the server level, turn Wordfence’s scheduled scan off and leave everything else alone.

1. In WordPress admin, go to Wordfence > Scan, then open Scan Options and Scheduling.
2. Find Schedule Wordfence Scans and set it to Disabled. (Older versions of the plugin show this as a checkbox to untick.)
3. Save Changes.
4. If a scan is running right now, press Stop on the Scan page. It stops at its next step, usually inside a minute.

Nothing else changes. The firewall keeps running, login security keeps running, blocking rules stay as they were, and you can still press Start New Scan whenever you want one. That is the sensible time to scan anyway: after an update, after a change, or the moment something looks wrong.

Turning Off Wordfence Scans Across a Whole Server

Doing the steps above on thirty sites by hand is a long afternoon. This is the one-line script we actually ran, as root over SSH, on our WHM server. It stopped the scans and the server recovered.

for d in /home/*/public_html; do [ -f "$d/wp-config.php" ] && wp --path="$d" --allow-root eval 'if (!class_exists("wfConfig")) { echo "no wordfence\n"; return; } wfConfig::set("scheduledScansEnabled", 0); if (class_exists("wfScanner")) { wfScanner::shared()->unscheduleAllScans(); } if (wfConfig::get("wf_scanRunning") && class_exists("wfScanEngine")) { wfScanEngine::requestKill(); echo "scans off, running scan stopped\n"; } else { echo "scans off\n"; }' 2>/dev/null | sed "s|^|$d: |"; done

What it does, step by step

• Loops through every account’s public_html on the server.
• Skips anything that is not WordPress. It only acts where it finds a wp-config.php.
• Uses WP-CLI to run a few lines of PHP inside each site.
• Skips sites without Wordfence, printing no wordfence so you can see it did.
• Turns off scheduled scans by setting scheduledScansEnabled to off. That is the same stored setting the Schedule Wordfence Scans control writes.
• Clears any scan already queued for the future, which is what Wordfence itself does when you turn that option off in the admin.
• Stops a scan that is running right now, the same as pressing Stop on the Scan page.
• Prints one line per site, so you can see exactly what happened where.

It changes nothing else. Not the firewall, not login security, not blocking rules, not any other Wordfence setting, not other plugins, not a single line of site content. Manual scans still work afterwards.

What it does not cover

• Sites that do not live in /home/<user>/public_html, such as addon domains with their own document root. Handle those individually.
• Only the server it runs on. Run it on each server you manage.
• It needs WP-CLI installed and root access over SSH.

What to Take Away From This

• A slow site on shared hosting is not always the site’s fault. Before you optimise images and audit plugins, find out what else is running on the machine.
• Monitoring that only checks cached pages will tell you everything is fine. Watch uncached and logged-in load times as well, or you will find out from a client instead.
• Do not assume a stuck scan will clear itself. The documented behaviour says each step gives way after 45 seconds. Ours sat there for minutes. Stop them rather than wait them out.
• Do not run two malware scanners. If your host scans at the server level, let Wordfence do the two things it does better than anyone: the firewall and login protection.
• If you host many WordPress sites, check this before it bites you. It does not announce itself. It just looks like a server that has quietly got slower.

Our own LiteSpeed hosting runs Imunify360 malware protection at the server level, which is why none of our hosted clients need Wordfence scanning layered on top of it. And the reason we caught the gap between a green dashboard and a slow site at all is Service Sentinel, our own website monitoring, which is now watching uncached response times too.