The site
The site worked. Pages loaded, orders came in, and nobody had reported a problem. It runs on the company’s own server rather than on managed WordPress hosting, so the PHP settings were whatever the server had been set up with.
Both problems below had been there for years. They were found within an hour of connecting the site to monitoring that looks inside WordPress.
What Operanse raised
The plugin was installed and connected at about 22:50 local time. By 23:11 the site’s overview showed two problems, one of them critical.
The PHP code cache was full and mostly missing. PHP keeps compiled code in a shared cache (OPcache) so it does not have to read and compile every file on every request. This server still had the default size: 128 MB, with room for 10,000 files. That is less than the site’s code needs. Since PHP last started, eleven days earlier, the cache had answered only 40 % of lookups and had been reset 17 times, so most requests recompiled code they had compiled before.
One outside service was failing on almost every call. The site’s calls to api.wordpress.org were failing: 100 of 100 in the first hour, each in about one second. Every other service the site talks to, including Facebook, Wordfence and Yoast, was answering normally.
Finding the cause
The cache was straightforward: the readings said what was wrong and what usually fixes it.
The failing calls took more digging. The server could reach api.wordpress.org without trouble: WordPress’s own update checks went through, and so did a request by hand. But every call that failed did so in almost exactly one second. That looks like a timeout set by the code making the call, not a network fault.
A short logger, left on the site for three minutes, recorded which plugin made each failing call. Every one came from the same place: a compatibility check that Facebook for WooCommerce runs on every admin request. It asks api.wordpress.org for the list of WooCommerce versions, allows one second for the answer, and keeps the list for a week once it arrives. From this server the answer takes about two seconds. So it never arrived, nothing was ever kept, and the plugin asked again on the next admin request.
| Reading | Before | After |
|---|---|---|
| OPcache hit rate | 39.8 % | 98.8 % |
| OPcache memory used | 100 % | 62 % |
| OPcache resets since PHP started | 17 | 0 |
| api.wordpress.org calls failed, per hour | 100 of 100 | none |
| Time to each failure | 1.0 s | — |
/plugins/info/1.0/woocommerce.json t=1 admin -> http_request_failed: cURL error 28: Operation timed out after 1000 milliseconds with 0 bytes receivedWhat it cost
None of this produced an error page, a PHP error or a broken feature. The admin felt slow and the site was slower than it needed to be, and that was all anyone would have noticed, for years.
- Every page did more work than it needed to. With most cache lookups missing, PHP was recompiling code on page loads, for visitors and staff alike.
- Every admin request waited an extra second, then gave up. That covers admin pages and the background requests the editor and page builder make while someone works. In the two hours we watched, that was 327 failed calls, each a second of waiting. Visitors were not affected; the check skips the public site.
The fixes
Both were made by hand on the server. Operanse reads a site; it does not change one.
- The cache: a three-line PHP configuration file raising it to 512 MB and 65,000 files, then a graceful PHP reload. Within minutes it was answering 98.8 % of lookups, with no resets since.
- The admin timeout: a five-line must-use plugin that gives that one request five seconds instead of one. The check succeeded on the next admin request, kept its list for a week, and the failures stopped. Nothing in Facebook for WooCommerce was edited, so the fix survives its updates.
Why nothing else caught it
Both problems lived where ordinary monitoring does not look. An uptime monitor sees a site that answers, and this one always answered. Error logs record errors, and a full cache is not an error: PHP just does more work. A failed outside call that its plugin quietly ignores never reaches a log or a screen. The only sign was a second of waiting, spread across every admin click.
Operanse measures from inside WordPress: the PHP cache’s own counters, and every outside call the site makes, with how long it took and whether it failed. A setting that has always been wrong stands out against fixed limits from the first hour, before Operanse has learned what is normal for the site. How Operanse monitors a site.
If you want to check your own site
- The PHP cache. Ask your host, or look at a
phpinfo()page served by the site itself (the command-linephp -ioften reads a different configuration), foropcache.memory_consumptionandopcache.max_accelerated_files. If the site has more PHP files than the second number, or the cache’s hit rate is well below 95 %, it is too small. - A slow admin. If every admin page takes about a second longer than it should, look for a plugin making an outside call with a short timeout. The free Query Monitor plugin lists every outside call a page made and how long each took.
- Your PHP error log will not show either problem, but it is still the first place to look when something is wrong. The PHP error log reader groups a pasted log by cause.
Server readings like the PHP cache are on Insight; outside-service health is on every paid plan. Compare plans.