ZeroFatal – PHP Fatal Error Monitor & Crash Detection

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.