Allowed memory size exhausted
PHP reached the ceiling it was given and stopped. The number in the message is the limit, not the amount your site needs.
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)
Raise the limit enough to get the site back, then find what consumed it. A limit raised without that second step gets raised again next month, and the number in the message tells you nothing about which code was responsible.
What causes it, most likely first.
Work down the list. Each check is written to rule its row in or out before you change anything, because the fixes below it are different and a guess costs more than a command.
| Cause | How to check | Fix |
|---|---|---|
| An image being resized | The error appears on upload or on a media-library screen, and the file involved is large. | Give the resize enough memory or resize before upload. A camera JPEG can need many times its file size to decompress. |
| A query loading everything into an array | The error lands on an archive, an export, or a report - anywhere posts_per_page is -1. | Paginate the query. Fetching every row to count them is the most common version of this in plugin code. |
| Autoloaded options grown large | The autoloaded size is measured in megabytes. Every request pays it, so the error can appear anywhere. | Move the largest options off autoload. Plugins that store logs or caches in wp_options are the usual reason. |
| The limit is simply low | The message names a limit well under 256M on a site with an ordinary plugin set. | Raise WP_MEMORY_LIMIT to something modern. A 40M default is a decade out of date. |
| An import holding every row | Memory climbs steadily through a long-running job rather than spiking at once. | Process in chunks and free each batch. Memory that only ever grows is a job that never releases what it has read. |
Fixing it, step by step.
Commands assume WP-CLI and shell access. Where you have neither, each step says what it is doing so it can be done from the dashboard or over SFTP instead.
Read the limit you are actually hitting
There are two: PHP's own, and WordPress's own on top of it.
php -i | grep '^memory_limit' wp config get WP_MEMORY_LIMIT
Raise it enough to load the site again
This is triage. It buys you the dashboard back so you can do the next step.
wp config set WP_MEMORY_LIMIT '256M' wp config set WP_MAX_MEMORY_LIMIT '512M'
Measure the autoloaded options
Every request pays for this before it does anything else.
wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS mb FROM \$wpdb->options WHERE autoload='yes';"
Find the biggest offenders by name
The top of this list is usually one plugin storing something it should not.
wp db query "SELECT option_name, ROUND(LENGTH(option_value)/1024, 1) AS kb FROM \$wpdb->options WHERE autoload='yes' ORDER BY LENGTH(option_value) DESC LIMIT 10;"
Confirm the fix under the original limit
Put the limit back to where it was and reload the page that failed. If it holds, you fixed the cause rather than the symptom.
wp config set WP_MEMORY_LIMIT '128M'
What the platform takes off the list.
Memory is sized from the plan rather than from a shared default, so the starting point is a modern number instead of a decade-old one, and it belongs to your container alone. The dashboard shows the memory a site is actually using against what it has, which is the measurement that turns this error from a guess into a decision.
Questions, answered.
How much memory does WordPress need?
Why does the message mention a tiny allocation?
Can I raise the limit forever?
Why does it only happen in wp-admin?
If that was not it.
These fail in ways that look similar from the browser.