In the wild
These are the kinds of problems Logystera surfaces on real WordPress sites — the ones that don’t trip an uptime check or a security-plugin dashboard, because the server keeps answering and no threshold gets crossed. Details are anonymized; the patterns are real. Each card links to the full guide on how the signal works and what to do about it.
Security
The login page looked quiet. The REST API didn't.
A security plugin reported nothing unusual — no IP crossed its failed-login threshold. Underneath, a slow credential-stuffing run was probing the REST API a few attempts at a time per IP to stay below that line. Logystera flagged the aggregate authentication pattern across endpoints rather than the per-IP count, so the campaign surfaced while it was still spreading out.
Crash
“There has been a critical error on this website.”
A plugin update left the site returning WordPress’s generic critical-error page. The host’s uptime check still saw an HTTP response, so nothing alerted. Logystera caught the php.fatal signal the moment it started and attached the failing file and line, so the fix didn’t wait on a customer complaint.
Crash
A PHP upgrade that “worked” — and quietly filled the disk.
After a host bumped PHP a major version, every page load appended a dozen deprecation notices to debug.log. The site looked fine until the log volume itself became the problem. Logystera surfaced the php.warning rate climbing right after the version change, which points at the upgrade as the likely trigger.
Crash
Intermittent 500s that never showed up in a spot-check.
The site returned 500 Internal Server Error for some requests and loaded normally for others — the kind of intermittent failure a manual check almost always misses. Logystera tracks the error rate by status and route, so the pattern stayed visible even though any single page load might succeed.
Crash
A blank white screen where a page used to be.
No error, no styling, just an empty rectangle — and wp-admin locked out too. A white screen of death usually traces back to a fatal error with display disabled. Logystera already had the underlying php.fatal event captured, so the cause was a lookup rather than an afternoon of toggling plugins.
Crash
“Allowed memory size exhausted” — once every couple of weeks.
A rare, intermittent memory fatal that never reproduced on demand. Because Logystera records each occurrence with its route and timing, the pattern behind “it’s never the same page” became visible — enough to correlate it with a specific heavy operation rather than guess.
Operations
A scheduled post stuck at “Missed schedule.”
Posts scheduled for 09:00 were still unpublished past noon. WP-Cron depends on site traffic to fire, and on a quiet site it can silently stall. Logystera watches for the absence of expected cron runs, so a stalled scheduler shows up as a gap instead of as silence.
Operations
A plugin nobody remembers turning on.
An active plugin appeared that no one on the team enabled — or a caching plugin that quietly deactivated after an update. Logystera records plugin state changes as events, so “when did this change, and around what else?” is answerable instead of a mystery.
Security
wp-config.php changed two days ago. By whom?
A backup diff showed the site’s core config file had changed, with no obvious author. File-integrity signals record that a change happened — its size delta and timing — without shipping the file’s contents anywhere. That is often enough to place the change on a timeline and decide how worried to be.
Security
An Administrator account you didn’t create.
An unfamiliar admin user turned up in wp-admin. Whether it was added an hour ago or months back changes everything about the response. Logystera captures user and role changes as timestamped events, so the account’s creation lands on a timeline instead of an unknown.
