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…

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…

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…

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: Route your site’s mail through an SMTP service. Install any SMTP plugin from the plugin directory and…

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…

That is usually one of four things, all of them deliberate: 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. The source is muted. If the responsible plugin is ticked under Never email about, its errors are recorded and listed but never emailed. The error is not fatal. Warnings and notices are not emailed unless you enable those levels yourself. The crash happened too…

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.