The PHP errors your visitors hit, and you never see

Most of the errors that break your site for real people never reach you. They happen on the front end, out where the visitors are, in a code path you were not looking at, on a page you were not testing. The visitor sees a white screen or a broken layout, sighs, and leaves. The error itself drops into a log file that no one opens, and the site goes on looking perfectly fine from inside wp-admin. You find out weeks later, if you find out at all.

This is the quietest kind of WordPress problem. It is not a setting left open or a header you forgot to send. It is a fatal error that fires for a stranger and then disappears, and the gap between when it happens and when you hear about it is where revenue and trust leak out. This is a guide to closing that gap: what a captured fatal actually is, how to see them as they happen, and how to know whether the fix you pushed actually held.

What "a visitor hit a fatal" really means

A PHP fatal error is the kind that stops the page. Not a deprecation notice in a log, not a warning the visitor never notices. A fatal halts execution, and depending on your configuration the result is a blank page, a partial render, or the generic "There has been a critical error on this website" screen. Whatever the visitor sees, what they do not see is your content, and what you do not see is that it happened.

The reason these slip past you is structural. You browse your own site logged in, on pages you know work, in a browser session that behaves. The fatal that matters fires for someone on a page you rarely touch, triggered by a plugin interaction or a piece of data you do not have in your own account. The conditions that produce it are exactly the conditions you are unlikely to reproduce, which is why "it works on my machine" is the oldest line in software for a reason.

Catching them as they happen, not after

The fix for an invisible problem is to make it visible the moment it occurs. RecapWP's Errors area surfaces the PHP fatals captured from real visitor requests, and it does so in real time, without waiting for you to run a manual scan. The error monitor keeps its findings in step with the captured error log on every admin load, so the list you see when you open the dashboard reflects what has actually been happening out on the site, not a snapshot from the last time you remembered to look.

That distinction matters more than it sounds. A scan you have to remember to run is a scan that does not run. By keeping the error findings current automatically, the monitor turns "did anything break today" from a question you have to think to ask into one that is already answered when you log in.

One finding, not a flood

The same underlying bug rarely fires just once. A single broken function can be reached through three different templates, by a dozen visitors, across a hundred page loads, and a naive log would show you all of it as a wall of repetition. RecapWP deduplicates by the error message, so a fatal reached through three different code paths is one finding with a count beside it, not three findings competing for your attention.

That count is the useful part. It tells you whether you are looking at a freak event that happened once or a steady drip that is costing you visitors every hour. Worst-first ordering does the rest: the loud, recurring break sits at the top, and you spend your time where the damage is.

The error you never see is the one doing the most damage, precisely because no one is counting how often it fires.

"Resolved" is a clear, not an undo

Here is where the Errors area works differently from the rest of RecapWP, and the difference is deliberate. Most findings in the plugin carry a fix that the plugin applies and that you can reverse later from a ledger. A captured error does not, because there is nothing for the plugin to reverse. RecapWP did not cause the fatal, and it does not edit your code to remove it. The bug lives in your own code or in a plugin, and that is where the cause gets fixed.

So the action on an error is a one-way "Resolved" clear. It removes the monitoring record and nothing else. There is no rollback, because the plugin never changed your site, so there is nothing to roll back. A confirmation step guards the clear so you do not wipe a record by reflex. You read the finding, you go fix the underlying cause where it actually lives, and then you clear the record to say you have dealt with it.

It is worth sitting with why this is the honest design. A reversible undo would imply the plugin had done something to your code that it could take back. It did not. Pretending otherwise would be a worse product, not a friendlier one. The plugin's job in the Errors area is narrow and clear: surface the fatal, group the duplicates, track it, and get out of the way so you can fix the real thing.

The reappear signal: did my fix actually hold

Clearing a resolved error is not the end of the story, and this is the part that makes the feature more than a tidy log. If the same fatal happens again after you mark it resolved, it comes back on its own. The record reappears, with a fresh count, the next time a visitor trips the same break.

That reappearance is the single most useful signal the Errors area gives you. You found a fatal, you traced it to a plugin conflict or a bad assumption in a template, you pushed what you believed was the fix, and you cleared the record. The question that always hangs over a fix is whether it actually worked or only seemed to in your testing. A reappeared error answers it for you, in production, with real traffic. Silence means the fix held. A returning finding means it did not, and you get to know that from your own dashboard instead of from an angry email.

This closes the loop that logs alone never close. A log tells you something broke. It does not tell you whether your repair stuck. By letting a resolved error come back on its own, the monitor turns every fix into a small, self-checking experiment.

Make checking them part of the routine

Because the Errors area updates itself, the discipline it asks of you is small. You do not have to schedule anything or remember to scan. You have to look. Open the dashboard, glance at the Errors findings, and read what is sitting at the top.

A healthy site shows an empty or quiet list. A site with a real problem shows a high-severity fatal with a count that has been climbing while you were busy with other things. Either way, the few seconds it takes to check is the cheapest insurance you have against the worst kind of outage: the one your visitors know about long before you do. Pair it with the rest of your routine, the security findings and the updates and the broken links, and the front end stops being a place where problems go to hide.

The fastest way to find out what your own visitors have been hitting is to look at your own list. Run a scan, open the Errors area, and see whether anything has been quietly failing out there while the dashboard looked calm. If the list is empty, that is a good morning. If it is not, at least now you are the first to know.