Catch fatal errors before your client does

If you build or maintain WordPress sites for other people, you know the feeling: a message arrives that starts with “Is something wrong with the site?” — and your stomach drops, because you had no idea. By the time the client noticed, the site had probably been broken for hours.

The problem isn’t that things break. Things always break — a plugin auto-updates, a host bumps PHP, a snippet goes rogue. The problem is who finds out first. On the sites you don’t sit in front of all day, the default answer is: your client. That’s the relationship-damaging part, and it’s entirely fixable.

Why fatals slip through

A fatal error produces the white screen of death: a blank page, no visible error, nothing pushed to you. WordPress can email a Recovery Mode link to the site admin — but on a client site, that admin address is often the client’s, or a shared inbox nobody watches, or mail that silently fails. So the crash sits there, unreported, until someone stumbles onto it.

Homepage pingers help a little, but a lot of them only check the front page every few minutes and only tell you that it’s down, not what broke — so you still start from zero.

What good fatal monitoring looks like

For an agency or freelancer, effective monitoring has four properties:

1. It’s push, not pull. You get told; you don’t have to remember to check.
2. It survives the site being down. The alert can’t depend on wp-admin, because wp-admin might be part of what crashed.
3. It tells you the actual error. “The site is down” wastes ten minutes; “undefined function acme_init() in acme.php:42” saves them.
4. It leads straight to a fix. Ideally you can act from the alert itself, from your phone, without opening a laptop and an FTP client.

Setting it up

Here’s a practical setup that hits all four, using FatalGuard (the free tier covers everything below):

1. Install and activate. A self-installing drop-in starts watching every request immediately — no configuration, no wp-config editing.

2. Connect Telegram. Create a bot with @BotFather, paste the token, press Start. Now fatals are pushed to your phone. Because Telegram delivers the message, you get it even when the site is fully down — that’s property #2 handled.

3. Read the error in the alert. Each alert carries the error type, message, and file:line — property #3. You know what you’re dealing with before you’ve opened anything.

4. Fix from the alert. For a crashing plugin, the alert includes a one-tap “turn it off and restore the site” button. Tap it; the plugin is deactivated and the site is back — property #4, from your phone, in seconds.

For agencies running many sites, a few extras earn their keep:

• Routing — send a specific plugin’s fatals to the chat for the team that owns it.
• Stealth mode — keep your monitoring out of the client’s dashboard so it doesn’t invite questions or accidental deactivation.
• Error history + a weekly digest — so you can answer “when did this start?” and hand a client a regular health check.

Turn the worst message into a non-event

The goal isn’t to prevent every error — you can’t. The goal is to change the sequence of events. Today it’s often:

site crashes → hours pass → client notices → angry email → you scramble

With monitoring in place it becomes:

site crashes → alert in seconds → you tap “restore” → site back → client never noticed

Same crash. Completely different day. The difference is entirely about who hears about it first — and it should always be you.

Add FatalGuard to WordPress — it’s free and takes a minute to set up.