FAQ

Where’s this coming from?

Fatal Error Notify started as an internal tool on wpfusionplugin.com. We use the sales site to test beta releases of WP Fusion, and we wanted a notification to be sent if anything in our development releases affected the visitor experience.

In November of 2017, we ran a Black Friday promotion, and installed the Hustle — Pop-Ups plugin to announce the promotion. Shortly after setting it up, the site sent a notification that a fatal error had occurred during a submission of our support contact form.

The problem was that Hustle includes a class named CurlResponse as part of its Aweber integration (we weren’t using Aweber, but it was loading anyway), which conflicted with the same CurlResponse class in the Gravity Forms Helpscout plugin.

This prevented Gravity Forms from submitting. Bad!

Both Hustle and Gravity Forms Helpscout are made by very reputable developers (WPMU Dev and Rocketgenius respectively), but there’s no way they could have forseen this particular incompatibility.

If it weren’t for that notification, our contact and support forms would have been broken during one of the busiest weeks of the year, and it would have hurt business significantly. Thankfully we were able to quickly switch to a different popup plugin and didn’t have any more issues.

This and a couple of similar experiences made it clear that there was a real need for a solution that wasn’t being met. So we wrapped everything up into a plugin, added some additional options and tools, and here we are!

How is this different from WordPress’ built in recovery mode?

Since version 5.2, WordPress includes a recovery mode feature that can notify you about errors on your site, and allow you to enter the site in “recovery mode” to try and fix the problem. This works well for some errors, but not all:

1. Recovery Mode can only be triggered once per day by default, though this can be overridden with the recovery_mode_email_rate_limit filter
2. Recovery Mode is only triggered at “protected endpoints” such as the login page and WordPress admin. It isn’t triggered when a regular user encounters an error on your site
3. Recovery Mode isn’t triggered during AJAX actions such as form submissions or WooCommerce checkouts

As an example, you can add a line to your functions.php like non_existent_function() and try to log into your site. WordPress will detect the fatal error and send you an email (in addition to Fatal Error Notify).

But if you try the following in functions.php

function test_error() {
	non_existent_function();
}

add_action( 'wp_footer', 'test_error' );

The error will only be detected by Fatal Error Notify, since it occurs on the frontend of the site in the footer.

Or, as another example, we can simulate an error in a WooCommerce checkout like so.

function woocommerce_payment_complete( $order_id ) {
	$result = $order_id / 0;
}

add_action( 'woocommerce_payment_complete', 'woocommerce_payment_complete' );

This relatively common mistake results in a Uncaught DivisionByZeroError: Division by zero error, which breaks the checkout.

This error is reported by Fatal Error Notify, but not WordPress’ built-in error reporting since it happens in an AJAX (i.e. background) request.

This is why we recommend using Fatal Error Notify on any WordPress site.

 

How is this different from uptime monitoring?

It’s a great idea to use an uptime monitoring service with your site. This will let you know if your host is down, if your site gets taken down by a DDoS attack, or if anything else takes your site completely offline.

But as long as your home page loads, your site is considered to be “up.”

There are many situations where your site may load fine, but specific components may be broken. This often manifests itself in forms that fail to submit, or checkout pages that spin forever and don’t process a transaction.

It may be something that even the most thorough testing can’t check, like someone selecting a billing country that fails to load the correct states / provinces. Fatal Error Notify is designed to catch these problems and alert you to them, so you can fix the problem with a minimal amount of time and effort.

 

How does it send notifications if the site has crashed?

Fatal Error Notify can send a notification even during a “500” error, when your whole site appears to be offline and you just get a blank page. It does this by running in what’s called a “shutdown function.” Shutdown functions are triggered by PHP right before the server stops generating a page.

If a fatal error happens during a page load, the page stops loading, but shutdown functions are still executed.

In our tests, there is no type of error that Fatal Error Notify can’t catch, including “Out Of Memory” errors. But if you find one, let us know!

 

Why am I not receiving notification emails?

Because Fatal Error Notify sends emails that contain debugging information, they can sometimes get blocked by spam filters.

To confirm Fatal Error Notify is sending email, click the Send Test button on the main page of the plugin’s settings.

You can also use the plugin WP Mail Logging to confirm whether or not the emails are being sent. If the emails are showing in the outgoing mail log, then check your spam folder to see if the error reports have been marked as spam.

Note: If you are using a third-party SMTP plugin for outgoing mail, it’s possible for an error to happen before the SMTP plugin has loaded. In this case, Fatal Error Notify will try to send the notification, but it will not be sent. You can test this by temporarily deactivating your SMTP plugin.

If email error notifications aren’t working consistently with your SMTP plugin, we recommend using Slack for error notifications instead, as this is generally more reliable than email.

Testimonials

Once again, Fatal Error Notify is AMAZING. Always keeping me up to date on what it finds on the servers. We would NOT survive in production without it. Over the past 5 years it has:

• provided us with errors on paid plugins that we’ve asked (and luckily received) fixes from the plugin builders
• provided us with server down messages – allowing us to troubleshoot and adjust server settings and memory allocations
• provided us with access violations – allowing us to discover hack attempts and bad code, which we were able to fix by installing WordFence
• provided us with database connection blocks – allowing us to troubleshoot our MySQL connection settings
• provided us with notices and warnings – allowing us to fix namespace and class naming conflicts, as well as PHP upgrade issues / missing calls

Just a superior product, the database logging is a life-saver. On top of that, coupled with wp mail smtp plugin we can see a history of the emails sent from Fatal Error Notify, just incredible.

I think that FEN should be embedded in the WordPress core, I don’t know how any WordPress site lives without this plugin.

Thank you so much for an incredibly valuable tool.
Dan Linstedt
DataVaultAlliance