ZeroFatal – PHP Fatal Error Monitor & Crash Detection

Часто задаваемые вопросы

How can the plugin report an error when the site is already broken?

ZeroFatal registers a PHP shutdown function. PHP runs shutdown functions at the very end of every request, including requests that ended in a fatal error and returned a 500 response. So even when WordPress never finished loading and the visitor saw a white screen, ZeroFatal still gets one last chance to look at what went wrong, record it, and send the email.

Does this slow my site down?

No. On a request where nothing goes wrong, the shutdown handler reads one value, sees that there is no fatal error, and returns. It performs no database queries and loads no extra assets on the front end.

Does it send my error data anywhere?

No. Version 1.0 makes zero external HTTP requests of any kind. Everything is stored in a table in your own database, and the only thing that leaves your server is the notification email you configured.

Will it conflict with the WordPress critical error screen or recovery mode?

No. WordPress 5.2 and later ship their own fatal error handler and recovery mode. ZeroFatal is an observer: it records what happened and leaves core’s handling completely untouched.

Can it catch errors in a plugin that loads before ZeroFatal?

At runtime, yes — any fatal error during the request is caught, whichever plugin caused it. The one gap is a fatal error that happens while an earlier-loading plugin’s files are still being included, before ZeroFatal itself has loaded. Plugins load alphabetically, so ZeroFatal catches everything from zerofatal onwards at load time, plus everything from every plugin at runtime.

Why is the default view «Fatal» rather than «All»?

Because a list flooded with deprecation notices hides the one error that actually took your site down. Fatal errors are shown first by design. The other views are one click away.

What happens to my recorded errors if I deactivate the plugin?

Nothing. They stay in the database and are still there when you reactivate. Deactivating only stops the scheduled events.

Deleting is different: it removes the table, the settings, the transients and the scheduled events, leaving nothing behind. That is deliberate — a plugin you have deleted should not keep occupying your database.

I deleted the plugin, reinstalled it, and my old errors are gone. Why?

Because deleting a plugin in WordPress runs its uninstall routine, and ZeroFatal’s drops the error table. A reinstall then creates a fresh empty one. There is no way to recover the old rows afterwards.

If you only want to switch the plugin off for a while, use Deactivate rather than Delete — that keeps everything.

If you are migrating a site, reinstalling, or troubleshooting and you want the history to survive a delete, tick Keep my recorded errors and settings under Storage on the settings page before you delete. Your error history and configuration will then still be there when you install it again. It is off by default, because most people deleting a plugin expect it to clean up after itself.

Where does the «How to fix this» advice come from? Is it AI?

No. It comes from a library of rules written into the plugin and shipped with it. ZeroFatal matches your error against that library on your own server and shows you the entry that fits.

Nothing is sent anywhere to produce it. Your error messages, file paths and site details never leave your server, and the advice works exactly the same with your site offline. There is no AI involved and no service to sign up for.

The trade-off is honest: a fixed library cannot recognise every possible error. Roughly two thirds to three quarters of real-world fatal errors match a specific rule. Anything that does not still gets the general guidance for tracking down a plugin conflict, which is the method an experienced developer would use anyway.

The advice says to deactivate a plugin. Is that safe?

Steps are always ordered safest first, and nothing that changes how your site behaves appears without a warning telling you to take a backup and to test on a staging copy if the site is live.

ZeroFatal never makes any of these changes for you. There is no «fix it for me» button, and there never will be — the plugin diagnoses, you decide. It will also never tell you to edit a WordPress core file, and never suggests hiding an error rather than fixing it.

I get several ZeroFatal emails at once. Can that be calmed down?

Yes — the default already does. Set When to send on the settings page.

Why this needs handling at all: a throttle alone limits how often one error can email you, but three different errors each carry their own throttle. Because they usually start at the same moment, their timers would also expire at the same moment — landing two or three emails in the same minute.

Grouped, the default, fixes that. A fatal error that takes your site down still emails you the instant it happens, because a site that is down cannot be relied on to run a scheduled task. Everything after it, and every warning or notice, waits a few minutes and arrives as a single email listing them all. Once a day is quieter still, at the cost of possibly not hearing about a crash until the next day. Immediately restores the old one-email-per-error behaviour.

What is the difference between the grouping window and the throttle?

They answer different questions, which is why both exist.

The grouping window (default five minutes) is how long ZeroFatal waits, collecting different errors, before sending one email about all of them. It controls how many emails you get.

The throttle (default sixty minutes) is how long before the same error may be mentioned again. It stops one crash in a loop from filling every email. The occurrence counter keeps rising in the background either way, so nothing is lost.

ZeroFatal’s emails go straight to my spam folder. How do I fix that?

This is a mail authentication problem rather than a ZeroFatal one, and the same fix improves every other email your site sends.

By default WordPress hands mail to PHP’s mail() function, which sends nothing that proves the message really came from your domain. Gmail, Outlook and the rest treat unverified mail with suspicion, and a default sender address of wordpress@yourdomain.com — a mailbox that usually does not exist — makes it worse.

Three things fix it, in order of how much they matter:

1. Route your site’s mail through an SMTP service. Install any SMTP plugin from the plugin directory and connect it to a real sending service. It takes over wp_mail() for the whole site, so ZeroFatal needs no configuration for it.
2. Set the sender to an address that actually exists on your domain, rather than the WordPress default.
3. Add SPF and DKIM records to your DNS. Your sending service gives you the exact values. Without them, nothing else reliably keeps mail out of spam.

To check your progress, put a mail-tester.com address in the notification email field and press Send Test Error. It scores the message and names whatever is still missing. The full checklist is on the settings page, under the Send Test Error button.

I pressed Send Test Error but no email arrived. What is wrong?

Almost always this is your site’s mail setup rather than ZeroFatal. The plugin hands the message to WordPress with wp_mail() and its job ends there — it does not contain a mail server and does not use any third-party sending service.

By default wp_mail() falls back to PHP’s mail() function, which needs a working mail server on the machine. On a local development site (WAMP, XAMPP, Laragon, MAMP) there usually is not one, so nothing is ever sent. On live hosting it often does send, but without SPF and DKIM records set up for your domain, providers such as Gmail and Outlook frequently drop the message or file it as spam.

The fix is the same one used for every other WordPress email, from order receipts to password resets: install an SMTP plugin from the plugin directory and point it at a real sending service. ZeroFatal needs no configuration for this — the SMTP plugin takes over wp_mail() and ZeroFatal’s emails start going out with everything else. If you are testing locally, a mail-catcher tool such as Mailpit or MailHog will show you the message without sending it anywhere.

Also worth checking: that Email notifications is ticked on the settings page, and that the notification address is one you can actually read.

An error is showing in my list, but I never got an email about it.

That is usually one of four things, all of them deliberate:

1. The throttle. After the first email about a particular error, ZeroFatal stays quiet about that same error for the length of your notification throttle, one hour by default. The occurrence counter keeps rising in the background. A different error still emails you straight away.
2. The source is muted. If the responsible plugin is ticked under Never email about, its errors are recorded and listed but never emailed.
3. The error is not fatal. Warnings and notices are not emailed unless you enable those levels yourself.
4. The crash happened too early. wp_mail() is loaded partway through WordPress startup. A fatal error that strikes before that point is still captured and stored — you will see it in the list — but there is no mail function available yet to send it with. Recording it and staying quiet is safer than trying to send from a half-loaded site and causing a second crash.

Can I stop being emailed about one noisy plugin?

Yes. On the settings page, tick that plugin under Never email about. Its errors are still recorded and listed, they just stop arriving in your inbox.