Don’t give up! Timeouts and “allowed memory size exhausted” are the two walls a WordPress request can hit: it took too long, or it needed too much memory. They are annoying, very common, and most of the time they share the same cause and the same fix.
In 30 seconds
- Both are limits, not bugs. The server stops any request that runs too long or uses too much memory, so one heavy task can’t take the whole site down.
- Read the error to know which limit you hit. The table below sorts them out.
- Fix the cause first: fewer plugins, a modern PHP, a lighter database.
- Raise the limit only after that, and modestly (60 seconds, 256 MB). A higher limit hides the problem, it doesn’t remove it.
Which error do you have?
Depending on the server and where the request dies, the message is slightly different, even though the cause is often the same annoying one 😬
| You see | What it means |
|---|---|
| Maximum execution time of 30 seconds exceeded | PHP itself stopped the script because it ran longer than max_execution_time. |
| Allowed memory size of X bytes exhausted | PHP stopped the script because it needed more than memory_limit. |
| 504 Gateway Timeout | The web server or proxy in front of PHP gave up waiting for an answer. |
| Error 524: A timeout occurred | Cloudflare reached your server, but your server didn’t answer within 100 seconds. |
| 408 Request Timeout | The server got tired of waiting for the browser to finish sending its request (a slow connection or a big upload). Rarely WordPress’s fault. |
| There has been a critical error on this website | WordPress caught a fatal error. It can be either limit, or something else entirely. |
For that last one, the real message is in the email WordPress sends to the site admin, or in your debug log. Here is how to find it: How to find and read your PHP error logs.
The memory error looks like this, and the numbers are in bytes:
Fatal error: Allowed memory size of 805306368 bytes exhausted (tried to allocate 130023440 bytes) in /wp-content/plugins/somewhere.php on line X| Bytes in the message | Memory limit |
|---|---|
| 33554432 | 32 MB |
| 67108864 | 64 MB |
| 134217728 | 128 MB |
| 268435456 | 256 MB |
| 536870912 | 512 MB |
| 805306368 | 768 MB |
| 1073741824 | 1 GB |
Why does it happen?
When a request hits a limit
PHP runs WordPress, your theme and your plugins. Basically, everything that makes your website. To protect itself, the server gives each request a time budget and a memory budget. When a request goes over either one, it gets stopped. Most servers use 30 seconds, and that’s actually not a bad choice: a normal page should take a fraction of that.
Okay, but why is WordPress so slow or so hungry? For every single request (including the background ones), WordPress loads itself, and so does every active plugin. Then some of those plugins decide to do something heavy on top: an update check against a slow remote server, an import, image processing, a huge database query. Everything is possible. The plugin named in the error is where the limit was reached, which isn’t always the plugin that used up the budget.
Fix the cause first
There are basically two solutions: optimize, or raise the limits. The first one is my recommendation, and you should try things in this order.
Disable the plugins you don’t need
Have a look at your Plugins list and disable the ones you don’t really need. Not only will you get rid of the error, you will also make your WordPress faster. If you need all of them, check their options: maybe some heavy processing can be switched off.
Use a modern PHP
Make sure your host runs PHP 8.3 or newer. Recent versions run the same code faster, with zero work on your side. Most hosts let you switch in one click.
Measure before and after
If you have any Meow Apps plugin installed, open Meow Apps → Dashboard and start the speed test. The Empty Request Time is how long your WordPress takes to answer a request that does nothing at all. Under 500 ms is healthy. Over 2,000 ms, timeouts will come back regularly. Deactivate one plugin, run the test again, compare, and you will find the heavy one. The full method is here: How to: Make WordPress Faster & Optimize It.
Check your autoloaded options
On every request, WordPress loads all the “autoloaded” options from the database into memory. Plugins sometimes store big things there and leave them behind, even after you uninstall them. WordPress’s Site Health starts warning when they go over 800 KB. To see which ones are heavy, Database Cleaner lists your options with their size in its Options tab (Expert mode), and lets you turn autoload off for the big ones or delete the leftovers. Back up first, as always.
Then raise the limits (a little)
You might not be able to do this by yourself if it’s not your own server, and that’s fine: your hosting service can do it for you in a minute. But just in case, here is how.
Memory limit
Add this line to your wp-config.php, above the line that says “That’s all, stop editing”.
define( 'WP_MEMORY_LIMIT', '256M' );This one applies to the front end of your site. The admin already gets up to 256 MB by default, so if the error happens there, raise WP_MAX_MEMORY_LIMIT instead. WordPress only ever raises PHP’s limit, never lowers it, and it can’t go past a limit your host has locked. In that case, the setting lives in your php.ini (memory_limit = 256M). You can try 512M, but you shouldn’t go above that.
Max execution time
If you have access to your php.ini, look for max_execution_time and set it to the number of seconds you would like, 60 for example.
max_execution_time = 60No access to php.ini? Most hosts run PHP as PHP-FPM, and then the same line works in a .user.ini file at the root of your WordPress install. If your server runs Apache with PHP as a module (and only then), you can add this to your .htaccess instead. On any other setup, this line breaks the site with a 500 error, so remove it if that happens.
php_value max_execution_time 60If you set the value to 0, the process is allowed to run forever. Don’t do this, you will run into much bigger issues, extremely difficult to resolve.
On NGINX, the web server has its own timeout for PHP. In your site’s server block, raise it to match, then reload NGINX:
fastcgi_read_timeout 120;Developers can also call set_time_limit( 120 ); right before a long task in their own code, so only that task gets the extra time. Don’t put it globally in your theme’s functions.php, and know that some hosts disable it.
The one limit you can’t raise: if your site is behind Cloudflare, it waits 100 seconds, whatever PHP is allowed. A task that needs longer has to be split into smaller batches. That’s how our own plugins handle big jobs.
Quick answers
Should I just raise the limits and move on?It’s the easiest (and laziest) fix, and it works for a while. But a page that needs 60 seconds is a page your visitors leave. Find what’s heavy first, then raise the limit a little if you still need it.
The error names a plugin. Is that the culprit?Often, but not always. It names the code that was running when the budget ran out. Disable it to check, and if the error moves to another plugin, the problem is the whole stack, not that one plugin.
I can’t change any of these settings. What now?Contact your hosting service. Ask them for PHP 8.3 or newer, a 256 MB memory limit and a 60 second execution time. A good host does it in minutes. If yours can’t, it might be time for a better host.
