Out of memory errors | WP Debug Toolkit

When PHP exceeds its memory limit, WordPress crashes with a fatal error. WP Debug Toolkit (WPDT) detects these out-of-memory (OOM) errors and sends you a notification, even though the process that triggered the error is already dead.

What an OOM error looks like

A typical OOM error in debug.log:

[15-Mar-2026 14:32:10 UTC] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted
(tried to allocate 65536 bytes) in /wp-content/plugins/example-plugin/includes/class-import.php on line 215

This means PHP hit the 256 MB memory limit while the example-plugin was trying to allocate another 64 KB. The process is killed immediately — no more code runs after this point.

How WPDT handles OOM errors

OOM errors are one of the hardest errors to handle because the process runs out of the one resource it needs to report the problem: memory. WPDT’s MU-plugin uses a memory reservation technique to work around this.

Memory reservation

When the MU-plugin loads (before any other plugin), it reserves 256 KB of memory:

self::$memory = str_repeat('*', 1024 * 256);

This reserved block sits unused during normal operation. When PHP hits the memory limit and triggers a shutdown, the MU-plugin’s shutdown handler runs and immediately releases the reserved block:

self::$memory = null;

This frees 256 KB — enough for the handler to build and send a notification email about the fatal error.

Notification delivery

The MU-plugin treats OOM errors as fatal E_ERROR events. When one occurs:

The shutdown handler releases reserved memory
It reads the last error via error_get_last()
It builds a notification email with the error details
It sends via wp_mail(), with a fallback to PHP’s native mail() function if wp_mail() fails (which it might, since WordPress may be in a broken state)

Error hash normalization

OOM errors from the same source produce slightly different messages each time (the “tried to allocate X bytes” part varies). WPDT normalizes these messages before hashing by stripping the byte counts, so repeated OOM errors from the same location share a single hash. This prevents rate limiting from treating each OOM as a unique error and flooding your inbox.

Recovery mode integration

OOM errors are recoverable by WordPress. When one occurs, WordPress enters recovery mode (since WordPress 5.2) and sends a recovery email with a temporary login link. WPDT enhances this email with a link to the standalone viewer, which works even when WordPress is down, so you can inspect the error log immediately.

What you receive

When an OOM error triggers a notification:

Error details — the “Allowed memory size exhausted” message, the file and line number, and which plugin or theme was running
Recovery URL — a temporary link to log in and deactivate the offending plugin/theme
Viewer link — a direct link to the standalone viewer where you can see the full error log

Common causes

Importing large datasets — CSV imports, WooCommerce product imports, or media library bulk operations
Plugins loading entire datasets into memory — querying all posts, all users, or all orders without pagination
Image processing — resizing large images (especially with GD or Imagick) can require several times the image file size in memory
Recursive or deeply nested operations — plugins that trigger themselves recursively
Memory leaks in long-running processes — WP-Cron jobs or background workers that accumulate memory over many iterations

Prevention

Increase the memory limit

Set WP_MEMORY_LIMIT in wp-config.php to give WordPress more room:

define('WP_MEMORY_LIMIT', '256M');

This cannot exceed the server’s PHP memory_limit in php.ini. If the server allows 128 MB, setting WP_MEMORY_LIMIT to 256 MB has no effect.

WPDT can set this from Settings > PHP Settings > Memory Limit, on hosts where wp-config.php is writable.

Identify the source

The error message includes the file path and line number. Check which plugin or theme is responsible:

/wp-content/plugins/plugin-name/ — that plugin
/wp-content/themes/theme-name/ — that theme
/wp-includes/ or /wp-admin/ — WordPress core (rare for OOM)

Use the standalone viewer’s error log to find the full error and inspect the source file (hover over the entry and press Q).

Monitor trends

If OOM errors recur, check whether they correlate with specific actions (imports, cron jobs, specific pages). WPDT’s Site Monitor email notifications with rate limiting help you track these without inbox floods — the error hash normalization ensures repeated OOM crashes from the same source are rate-limited as a single error.