WP Debug Toolkit’s (WPDT) Email Notifier module sends email alerts when PHP errors occur on your site. WPDT installs a must-use plugin (wpdebugtoolkit-notifications.php) to wp-content/mu-plugins/ so the error handler activates before regular plugins load, capturing errors that occur during plugin initialization. Two rate-limiting mechanisms prevent inbox flooding: a per-error cooldown that suppresses repeat alerts for the same error, and a global hourly cap on total emails sent. Configure both in WP Debug Toolkit › Settings › Notifications.
WPDT’s Email Notifier module watches your site for PHP errors and sends you an alert the moment one occurs. You choose which error types trigger an alert, set the thresholds that control how often alerts fire, and configure one destination email address where all notifications land.
Each alert email includes the error type, message, file, line number, and a link to the WPDT standalone Viewer App. For recoverable fatal errors, the email also includes a link to WordPress Recovery Mode so you can regain admin access without FTP.
Production sites generate errors constantly: deprecation notices from theme updates, warnings from misconfigured plugins, and occasional fatal errors that bring a site down entirely. Without a notification system, you find out about these problems when a client calls.
WPDT’s notification system is designed to reach you first. Because WPDT installs its error handler as a must-use plugin rather than a standard plugin, it activates before other plugins load, which means it captures errors that occur during a plugin’s own initialization sequence. These are the class of errors most likely to crash a site and most likely to be missed by handlers that load later.
The notification system combines three distinct mechanisms. Each operates automatically once the MU-plugin is installed.
WPDT installs wpdebugtoolkit-notifications.php to wp-content/mu-plugins/. WordPress loads MU-plugins before regular plugins, and they cannot be deactivated through the plugins screen. WPDT registers its error handler and shutdown handler at this early load point.
php
// wp-content/mu-plugins/wpdebugtoolkit-notifications.php
// Loaded by WordPress before any regular plugin.
// WPDT registers its shutdown handler here so errors
// are captured even if a plugin crashes during its own
// load sequence.
register_shutdown_function( array( $handler, 'handle_shutdown' ) );WPDT installs three files to capture and notify on errors: the MU-plugin itself, a shared email-helpers.php file (also in wp-content/mu-plugins/) that builds the actual email content, and a fatal-error-handler.php drop-in in wp-content/.
The drop-in is a WordPress fatal error handler, and not a pre-WordPress hook. It extends WordPress’s native WP_Fatal_Error_Handler, lets WordPress run its own fatal error handling first (including recovery mode), and then calls into the MU-plugin to trigger the notification email. WPDT’s recoverable-fatal-error handling rides on top of WordPress’s existing recovery mode system rather than replacing it.
For recoverable fatal errors (E_ERROR, E_PARSE, E_USER_ERROR) WPDT hooks into WordPress’s recovery_mode_email filter to replace the default recovery email with a richer, WPDT-branded notification that includes stack traces and a direct link to the Viewer App. If WPDT’s email cannot be sent, WordPress’s native recovery email serves as the fallback.
For non-fatal errors (warnings, notices, and similar), WPDT registers a custom PHP error handler and batches up to 20 non-fatal errors per request into a single email sent at shutdown, rather than sending one email per error.
Out-of-memory errors present a specific reliability problem: when PHP exhausts its memory limit, the process terminates abruptly and standard error handlers and mail functions cannot run.
The MU-plugin solves this by reserving 256KB of memory at startup. That memory remains allocated and unused by the rest of the site until the shutdown handler fires, at which point WPDT frees it immediately before doing anything else. This happens on every shutdown, not only on those caused by memory exhaustion, ensuring that headroom is already available in the specific case where it’s actually needed.
Before checking rate limits, WPDT normalizes the error message to produce a stable hash. This normalization strips dynamic values that change between occurrences of the same underlying error without changing its meaning, e.g., memory allocation sizes in out-of-memory messages, file paths in file operation warnings, and similar variable segments.
Two occurrences of the same error that differ only in their dynamic values produce the same hash. WPDT then applies rate limiting to that hash, not the raw message, which prevents the same error from generating dozens of alerts when it repeats frequently.
✅ Key Guarantees
Navigate to WP Debug Toolkit › Settings › Notifications and expand Error Levels to choose which PHP error types trigger notifications. Click Select Recommended to apply the production-ready preset.
Recommended for Production: Fatal errors, parse errors, warnings, and user errors.
Common Error Types
| Error Type | Constant |
|---|---|
| Fatal Errors | E_ERROR |
| Warnings | E_WARNING |
| Parse Errors | E_PARSE |
| Notices | E_NOTICE |
| Deprecated | E_DEPRECATED |
| User Errors | E_USER_ERROR |
| User Warnings | E_USER_WARNING |
| User Notices | E_USER_NOTICE |
Advanced Error Types (expand the collapsible group in the UI to access)
| Error Type | Constant |
|---|---|
| Strict Standards | E_STRICT |
| Recoverable Errors | E_RECOVERABLE_ERROR |
| Core Errors | E_CORE_ERROR |
| Core Warnings | E_CORE_WARNING |
| Compile Errors | E_COMPILE_ERROR |
| Compile Warnings | E_COMPILE_WARNING |
Two rate limiting mechanisms control how often WPDT sends notification emails, and they work differently depending on the error type.
The per-error cooldown sets the minimum time before WPDT sends another alert for the same error. Once WPDT sends a notification for a given error, it suppresses further alerts for that same error until the cooldown period expires.
The configurable range is 60 seconds to 24 hours. This setting fully applies to recoverable fatal errors only. For warnings, notices, and other non-fatal error types, the cooldown is fixed at 24 hours regardless of what you set here.
The global hourly cap sets a ceiling on the number of fatal-error notification emails WPDT sends per hour. The configurable range is 1 to 100. This cap does not apply to non-fatal errors: warnings, notices, and similar types are limited separately to 5 emails per hour, a fixed limit that this setting cannot raise or lower.
In practice, this rarely matters, since non-fatal errors are also batched into a single email per request rather than sent individually, so the per-error cooldown is usually what controls how often you hear about a recurring warning.
Most suppressed alerts are recorded in Notification History. Navigate to WP Debug Toolkit › Settings › Notifications and scroll to the Notification History section to view the last 7 days of alert activity.
For full configuration instructions and a detailed explanation of how the alert history log works, see Rate Limiting and Alert History.
Navigate to WP Debug Toolkit › Settings › Notifications to access all settings below.
| Setting | What It Does |
|---|---|
| Email Notifications | Enables or disables the entire notification system. When set to Disabled, no alerts fire and no history entries are recorded. Toggle this off when running maintenance to prevent alert noise during expected error conditions. |
| Email Address | The address where all notification emails are delivered. Defaults to the WordPress admin email if left empty. Agencies managing multiple clients should enter a team inbox or client-specific address here rather than a personal address. |
| Error Levels | Selects which PHP error types trigger a notification. Use the Select Recommended preset to apply fatal errors, parse errors, warnings, and user errors — the correct baseline for most production sites. Expand the Advanced Error Types group to access E_STRICT, core errors, and compile-time errors, which are rare in production and disabled by default. |
| Per-Error Cooldown | Sets the minimum time before WPDT sends another alert for the same error. Accepts values between 60 seconds and 24 hours. The default is 1 hour. This setting fully applies to recoverable fatal errors only. Warnings, notices, and similar non-fatal types use a fixed 24-hour cooldown regardless of this value |
| Max Emails Per Hour | Sets the number of fatal-error notification emails WPDT can send per hour. Accepts values between 1 and 100. The default is 10. This cap does not apply to non-fatal errors (warnings, notices), which are limited separately to 5 emails per hour and cannot be changed by this setting. |
Note: Email notifications require an active Email Notifier Module license or any WPDT Pro plan. If the Notifications tab does not appear in WP Debug Toolkit › Settings, your current license does not include this module. See the WPDT pricing page to add the Email Notifier Module or upgrade to a Pro plan.
Likely cause: The notification email is being sent but filtered or routed to spam by your email provider, or the MU-plugin is not installed.
Fix: Navigate to WP Debug Toolkit › Settings › Notifications and scroll to the Must-Use Plugin section. Confirm the MU-plugin shows as installed. If it does not, use the install button in that section. Once the MU-plugin is confirmed as installed, click Send Test Email to confirm delivery. Check your spam folder and verify the email address in the Email Address field if the test email does not arrive. Note that WPDT falls back automatically to PHP’s native mail() function when wp_mail() is unreliable, but both require a functioning mail configuration on your server.
Likely cause: The per-error cooldown is set lower than the frequency at which the error is occurring, or multiple distinct error signatures are bypassing the per-error limit and accumulating toward the global hourly cap.
Fix: Navigate to WP Debug Toolkit › Settings › Notifications › Rate Limiting and increase the Per-Error Cooldown value. For recurring errors you want to silence temporarily, increase the cooldown to 6 hours or 24 hours. To understand which errors are triggering the most alerts, review the Notification History section, which records all sent and suppressed notifications for the past 7 days.
WordPress loads regular plugins after the core finishes initializing, which means a regular plugin’s error handler cannot capture errors that occur earlier in the load sequence, including fatal errors thrown by other plugins during their own initialization. A must-use plugin loads before any regular plugins and cannot be deactivated accidentally. WPDT places its error handler and shutdown handler in a MU-plugin specifically so no crash scenario falls outside its capture window.
Yes, for most suppressed alerts. WPDT records non-fatal suppressed alerts and suppressed duplicate fatal alerts to the Notification History log with the reason for suppression. Navigate to WP Debug Toolkit › Settings › Notifications and scroll to Notification History to see the full 7-day log. A suppressed entry shows the error signature and the suppression reason, so most rate-limited activity is visible after the fact.
When WordPress detects a recoverable fatal error and enters recovery mode, it generates a recovery URL linked to the problematic plugin or theme. WPDT intercepts this process via the recovery_mode_email filter and replaces the default WordPress recovery email with a richer notification that includes the full error details, a direct link to the WPDT standalone Viewer App, and the WordPress Recovery Mode link. If WPDT cannot send the replacement email, WordPress’s default recovery email fires as a fallback so you always receive the recovery URL.
Setting Up Notifications – Configure your recipient address, choose which error levels trigger alerts, and dial in your cooldown thresholds, all from the Notifications tab in WPDT Settings.
Rate Limiting and Alert History – See exactly how the per-error cooldown and hourly cap decisions are made, and how to read the 7-day history log to find alerts that fired silently.
Out of Memory Errors – Learn how WPDT keeps the notification pipeline alive even when PHP runs out of memory mid-request and what to do when an OOM alert lands in your inbox.
