WordPress memory exhausted: why visitors see a critical error while your dashboard works

Why does WordPress memory exhausted show a critical error?

A WordPress memory exhausted error happens when one page load asks PHP for more memory than the server allows. PHP stops the request, and WordPress shows its stock message: “There has been a critical error on this website.”

The message names nothing. The cause sits in the error log, in a line like this one from our lab:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 1052672 bytes) in /wordpress/wp-content/mu-plugins/lab-hog.php on line 8

134,217,728 bytes is exactly 128 MB. The end of the line is the useful part: it names the file and the line that went over.

Critical errors after a plugin update have their own section on our WordPress care and fixes page, with how we trace them.

How did we test it?

On 13 Oct 2026 we ran a fresh WordPress 7.1.3 site on WordPress Playground, with PHP 8.3.33 and no plugins installed.

Playground has no php.ini switch and allows 256M by default. So we simulated a host that allows 128M by putting ini_set( ‘memory_limit’, ‘128M’ ); at the top of wp-config.php. No real host was involved.

A small must-use plugin stood in for a heavy one, holding memory until the request reached a set size. We loaded the home page and login page as a visitor, and /wp-admin/ as an admin.

Why does the dashboard work when visitors see the error?

WordPress gives admins more memory than visitors.

Our plugin pushed each page to 150 MB as it rendered. The results:

Inside wp-admin, WordPress calls wp_raise_memory_limit(‘admin’) for users who can manage options. That lifts the limit to WP_MAX_MEMORY_LIMIT, 256M on our lab. In 7.1.3 the call is on line 167 of wp-admin/admin.php, before admin_init on line 180. The plugin reached 150.5 MB in the dashboard and the page loaded fine.

So the owner logs in, sees a working dashboard, and has no idea the home page is down.

What if the plugin loads on every request?

Then you are locked out as well. We moved the plugin’s memory use to init, which runs on every request before wp-admin raises anything.

The home page, the login page and /wp-admin/ all returned 500. Submitting the login form returned 500 too.

The login and admin pages added two sentences: “Please check your site admin email inbox for instructions.” and one that starts “If you continue to have problems, please try the”. The first points to the recovery mode email, which we explain in what the WordPress “technical issue” email means. Playground sends no mail, so we did not see that email in this lab.

Where does WP_MEMORY_LIMIT go in wp-config.php?

Open wp-config.php in the site’s root folder through your host’s file manager or SFTP. Add this line above the comment that says “That’s all, stop editing”:

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

With the same plugin still loading 150 MB on every request, that one line brought everything back. The home page, the login page and /wp-admin/ all returned 200 at 256M, and logging in worked.

WordPress’s own documentation recommends this constant when you see “Allowed memory size of xxxxxx bytes exhausted”. Its default is 40M on a single site. That was below the 128M our simulated host allowed, so it did nothing until we set it.

Why did WP_MEMORY_LIMIT 64M change nothing?

WordPress only raises the limit. It never lowers it.

We set WP_MEMORY_LIMIT to 64M on our simulated 128M host. The front page and the login page still ran at 128M.

So check what your host allows before you copy a value from a forum. Tools, then Site Health, then Info, then Server lists the PHP memory limit (our post on which Site Health critical issues to fix first walks through that screen). Only a higher value has any effect.

Why is raising the limit not the real fix?

A heavier plugin will hit the new ceiling the same way. We left WP_MEMORY_LIMIT at 256M and made the plugin need 300 MB.

Every page returned 500 again, admin and login included. The log line changed to “Allowed memory size of 268435456 bytes exhausted”, which is 256 MB.

WordPress’s documentation warns that raising the limit can hide the cause until you add more plugins. The limit buys time. The fix is the file named in the log: update that plugin, replace it, or ask its developer why one page needs that much memory.

This is the fix we do as a one-off job. We read the error log, find the plugin it names, and test the update or replacement on a copy of the site before it touches the live one.

When should you ask your host?

Ask your host when the line is in wp-config.php and nothing changes.

Some hosts block PHP from raising its own limit, or cap memory below what you set, and then the constant is ignored. The host can raise the limit or tell you the most your plan allows.

Ask too if you cannot find the error log. WordPress can also write one to wp-content/debug.log, but only when both WP_DEBUG and WP_DEBUG_LOG are set to true in wp-config.php.

If the same plugin breaks saving in the editor instead, the message there is different: see the “response is not a valid JSON response” error in WordPress.

If the site shows only “Error establishing a database connection” instead, the cause is the database, not PHP memory: see the “Error establishing a database connection” error in WordPress.

What did we not test?

• A host that blocks ini_set or caps memory below WP_MEMORY_LIMIT. We expect the constant to do nothing there, but did not see it.
• The recovery mode email, because Playground sends no mail.
• Raising the limit through php.ini, .user.ini or .htaccess.
• Real plugins. Our test plugin only holds memory. A real one may fail in a different place.

Is your site showing the critical error right now?

If the memory line is in and the error is still there, or the log names a plugin you cannot remove, tell us what the site shows and we will trace it with you.

Memory is not the only PHP limit that locks people out. A plugin upload that stops at “The link you followed has expired” is usually post_max_size, and our upload limit test shows which setting fixed it.