Fatal Plugin Auto Deactivator – Never let a plugin break your site

No, Fatal Plugin Auto Deactivator works automatically right after activation with no configuration required.

No, the plugin only activates its core functionality during the PHP shutdown phase and only takes action when a fatal error is detected.

The plugin catches fatal PHP errors, parse errors, and other critical errors that would normally crash your site.

Yes. An admin notice is displayed in your WordPress dashboard showing which plugin was deactivated and the specific error that caused it. Since 1.5.0 you can also enable instant notifications under Tools → Fatal Plugin Log → Settings: an email to one or more addresses and/or a webhook (generic JSON, or a Slack-compatible message you can point at a Slack/Discord/Mattermost incoming webhook). Alerts tell you what action was taken — a plugin that was automatically deactivated reads differently from a protected plugin that is still crashing and needs your attention. Identical repeated errors are rate-limited (configurable cooldown), and both channels have a “send test” button.

Emails and generic JSON webhooks carry the same details as the log entry: plugin name, outcome status, error type/message, file and line, the request URL, and PHP/WordPress versions. The Slack-compatible format is a compact summary — plugin, action taken, error, and file:line. That includes server file paths, so point alerts only at inboxes and endpoints you control. Webhook URLs must use https:// (plain http:// is allowed only for localhost). If a fatal happens so early that WordPress cannot send mail or HTTP requests yet, the alert is queued and delivered on the next normal page load.

Yes, you can reactivate the plugin through the normal WordPress plugins page. However, be aware that if the issue hasn’t been fixed, the plugin will be deactivated again if it causes another fatal error.

Yes. Go to Tools → Fatal Plugin Log → Settings and add the plugin to the “Protected plugins” list. Protected plugins are never deactivated automatically — for example, you may prefer to keep a checkout or payments plugin running and fix it manually rather than have it switched off. The fatal error is still logged and an honest message is shown on the error page.

Yes. Enable “Log-only mode” under Tools → Fatal Plugin Log → Settings. The plugin will keep detecting and logging fatal errors and showing the custom error page, but it will never deactivate a plugin.

The Fatal Plugin Log page shows a status banner (“Protection active” or a warning) with a “Protection last verified” heartbeat, and if the protection drop-in is missing, was replaced by another plugin, or could not be installed (for example because wp-content is not writable), you’ll see an admin notice and a Site Health test telling you, with a one-click “Reinstall protection” button. Since 1.5.0 an hourly background watchdog also re-verifies protection even when nobody logs in: it reinstalls a missing drop-in automatically, detects when the plugin folder was moved or when the WP_DISABLE_FATAL_ERROR_HANDLER constant disables fatal error handling entirely, and notifies you (via your configured alert channels, or the admin email) when protection is lost and when it is restored. Note that WordPress cron runs on site traffic — on a site with no visitors at all, configure a real server cron for wp-cron.php as usual.

Yes. The Fatal Plugin Log page lets you filter incidents by source (plugin, theme, must-use plugin, drop-in, core) and by status, search across the plugin name, error message, and file path, delete individual entries, and export the full log to CSV or JSON. Each row also has a “Copy” button that puts a ready-to-paste bug report (error, file, request URL, PHP/WordPress version) on your clipboard. Identical repeated fatals are grouped into a single row with an occurrence count.

The current version is designed for standard WordPress installations. Multisite support may be added in future updates.

The plugin compares the file path of the fatal error against the directories of your active plugins. When the error originates inside an active plugin’s folder, that specific plugin is deactivated. Errors originating outside the plugins directory — such as in a theme, a must-use plugin, a drop-in, or WordPress core — are still logged and shown on the custom error page, but nothing is deactivated.

The plugin determines the source of the error from its file path (theme, must-use plugin, drop-in, or WordPress core) and shows an honest message explaining that the issue could not be resolved automatically and may require manual attention. It will never claim to have fixed an error it could not act on. The error is still recorded in the Fatal Plugin Log, marked as logged only.

This plugin specifically targets fatal PHP errors that would normally make your site inaccessible. It doesn’t handle warnings, notices, or other non-fatal errors.

A drop-in is a special type of WordPress file that replaces core functionality. This plugin uses the fatal-error-handler.php drop-in to ensure it can handle errors even when other plugins fail. The drop-in is automatically installed when you activate the plugin and removed when you deactivate it.

WordPress allows only one fatal-error-handler.php drop-in at a time. While this plugin is active, it installs and maintains its own drop-in, replacing any existing fatal error handler drop-in so that error handling stays reliable. When you deactivate or uninstall this plugin, it removes only its own drop-in and leaves any non-related drop-in untouched.

For security reasons, detailed error information (file paths, line numbers, error messages) is only displayed on the front-end error page when WP_DEBUG is enabled and on-screen display is not turned off via WP_DEBUG_DISPLAY. (You can force details on or off with the FPAD_SHOW_ERROR_DETAILS constant.) Otherwise, visitors see a generic error message while administrators still receive detailed notifications in the dashboard. Every fatal error is always recorded in the Fatal Plugin Log (Tools → Fatal Plugin Log) regardless of the WP_DEBUG setting.

Error logs are stored in your WordPress database as options. The plugin maintains both temporary logs (for admin notifications) and a permanent log (for troubleshooting history) viewable under Tools → Fatal Plugin Log. Every detected fatal error is recorded in the permanent log, including errors that could not be attributed to an active plugin (such as those originating in a theme or in WordPress core) — those are marked as logged only, with no plugin deactivated.