WordPress Maximum Execution Time Exceeded
What Is This Error?
When WordPress runs a PHP script that takes too long to finish, the server cuts it off and throws a “Maximum Execution Time Exceeded” error. PHP has a built-in timer that caps how long any single script is allowed to run — the default on most shared hosting environments is 30 seconds.
This isn’t a WordPress bug. It’s a server-side safety net designed to prevent runaway scripts from consuming all available server resources. Think of it as a hard deadline: if the task isn’t done in time, the server pulls the plug and shows you this error.
You’ll most often run into this during plugin or theme updates, large data imports, thumbnail regeneration, and backup operations — tasks that do a lot of work inside a single PHP execution cycle.
Get free WordPress & AI tips
Join 500+ readers. No spam, unsubscribe anytime.
Why Does This Happen?
- Heavy plugin or theme updates: Some plugins run database migrations or process dozens of files during an update, which can easily blow past the 30-second default limit.
- Large data imports: Importing a WooCommerce product CSV or a big WordPress XML export triggers lengthy server-side processing that may time out before completing.
- Slow or overloaded shared hosting: On congested servers, even routine operations run slower than expected, making timeout errors far more likely.
- Backup plugins running large sites: Tools like UpdraftPlus or All-in-One WP Migration compress and transfer significant volumes of data in a single script run, which routinely hits the execution ceiling.
- Thumbnail regeneration: Regenerating image sizes for a large media library loops through hundreds of files, with each iteration adding to the total execution time.
How to Fix It — Step by Step
-
Method 1: Edit php.ini
This is the most reliable approach. Log into your hosting control panel (cPanel, Plesk, etc.) and locate the
php.inifile for your PHP version. Find the existingmax_execution_timeline or add a new one:max_execution_time = 300Save the file. Some hosts require a PHP-FPM restart — check your control panel or ask support if the change doesn’t take effect.
You should see: The operation that was failing (import, update, backup) now completes without a timeout error.
-
Method 2: Add a line to wp-config.php
Connect to your site via FTP or your host’s file manager and open
wp-config.phpin the root WordPress directory. Add this line directly before the line that reads/* That's all, stop editing! */:set_time_limit(300);Save the file and retry the operation that was timing out.
You should see: The task runs to completion with no timeout error appearing.
-
Method 3: Edit .htaccess (Apache servers only)
If your server runs Apache, open the
.htaccessfile in your WordPress root directory and add this line:php_value max_execution_time 300Save the file. Note: this directive is silently ignored on Nginx servers — use Method 1 or 2 instead if you’re on Nginx.
You should see: WordPress operations that previously timed out now complete normally.
-
Method 4: Ask your hosting provider
Some managed hosting environments (WP Engine, Kinsta, Flywheel) block direct PHP configuration changes. In that case, open a support ticket and ask your host to increase
max_execution_timeto at least 300 seconds. Most will do it without hesitation.You should see: A confirmation from support that the limit has been updated, after which your site runs the failed task successfully.
Common Mistakes When Fixing This
- Setting the value too low: Bumping the limit to 60 or 90 seconds and still seeing timeouts is a common frustration. Set it to at least 300 seconds — many backup and import processes genuinely need that headroom to finish cleanly.
- Editing the wrong php.ini file: Servers often have multiple php.ini files for different PHP versions. If your change has no effect, confirm which PHP version WordPress is using in your control panel and edit the matching configuration file.
- Using the .htaccess method on Nginx: The
php_valuedirective only works on Apache. On Nginx it is either ignored entirely or causes a 500 server error. Stick to php.ini or wp-config.php on Nginx hosts. - Not reloading after saving: After editing a server config file, some hosts require you to restart PHP-FPM before the new value takes effect. If nothing changes after your edit, ask your host whether a service reload is needed.
Frequently Asked Questions
Is it safe to raise max_execution_time to 300 seconds?
Yes, for the vast majority of WordPress sites this is completely safe. A higher limit simply gives long-running tasks more time to finish — it has no impact on regular page loads for your visitors, which typically complete in under a second anyway.
Why does this error only show up during certain operations?
Normal page requests finish in milliseconds and never come close to the limit. Timeout errors surface specifically during bulk operations — imports, backups, plugin updates — because those tasks do a large amount of work inside a single script execution rather than spreading it across multiple requests.
What is the difference between max_execution_time and set_time_limit()?
max_execution_time is a PHP configuration directive applied at the server level via php.ini. set_time_limit() is a PHP function you can call from within code (such as wp-config.php) to override that directive at runtime. Both control the same underlying limit — set_time_limit() is simply the code-level way to do it without touching server config files.
Will this error come back after I fix it?
It shouldn’t, as long as the new limit is generous enough. If you keep hitting timeouts even at 300 seconds, the operation itself may be inefficient — consider switching to a plugin that processes data in smaller batches, or look at upgrading to a faster hosting plan with dedicated resources.