The WordPress maximum execution time exceeded error appears when a PHP process takes longer to complete than the server allows. The full message typically reads: “Fatal error: Maximum execution time of 30 seconds exceeded in /home/user/public_html/wp-…” It is one of WordPress’s more common fatal errors, and it tends to surface at the worst possible moments — during a plugin update, an import, a backup process, or when someone with a large media library runs a regenerate thumbnails operation. The WordPress maximum execution time exceeded error does not mean your server is slow or broken. It means PHP’s built-in safety timer fired before a long-running task completed. That timer exists to prevent runaway scripts from hanging a server indefinitely, but on a standard shared hosting plan with a 30-second limit, legitimate WordPress operations hit it regularly. Every fix in this guide increases the execution time limit, identifies the operation responsible, or both — and all of them resolve the WordPress maximum execution time exceeded error without data loss. This fits into the wider topic we cover in our WordPress Errors Complete Guide.
What Triggers the WordPress Maximum Execution Time Exceeded Error
PHP enforces a max_execution_time limit on every script it runs. On most shared hosting plans, this is set to 30 seconds by default. On managed WordPress hosts and VPS environments, it is commonly 60 seconds, 120 seconds, or higher. The WordPress maximum execution time exceeded error fires the instant a script crosses the threshold — PHP terminates the process immediately, outputs the fatal error message, and rolls back nothing. Whatever the script was doing stops mid-operation.
The WordPress operations most likely to trigger the WordPress maximum execution time exceeded error are predictable once you understand which tasks take the longest. Plugin and theme updates that involve downloading large packages, extracting them, and writing many files can exceed 30 seconds on a slow server. Database-heavy operations like search-and-replace across a large content database, thumbnail regeneration across a media library with thousands of images, XML or CSV imports, and full-site backup creation are all operations that regularly produce the WordPress maximum execution time exceeded error on standard hosting plans with low limits.
It is worth distinguishing between a one-time WordPress maximum execution time exceeded error and a recurring one. A one-time error during an unusually heavy operation — importing 10,000 WooCommerce products, for example — may not require a permanent limit increase. A recurring error on routine operations like plugin updates suggests the time limit is genuinely too low for the site’s current complexity. Both situations have the same immediate fix but different long-term responses.
Fix the WordPress Maximum Execution Time Exceeded Error via php.ini
The most direct fix for the WordPress maximum execution time exceeded error is increasing the max_execution_time value in PHP’s configuration. The method available to you depends on your hosting environment, but one of the following will work on virtually any setup.
Option 1: Edit php.ini directly. On VPS servers, dedicated servers, and some managed hosts, you have access to the main php.ini configuration file. Locate it (typically at /etc/php/8.x/fpm/php.ini or similar, depending on your PHP version), find the line max_execution_time = 30, and change it to 300. Save the file and restart PHP-FPM (sudo service php8.x-fpm restart) or your web server for the change to take effect. A value of 300 seconds is sufficient for virtually all standard WordPress operations that produce the WordPress maximum execution time exceeded error.
Option 2: Create or edit php.ini in the WordPress root. Many shared hosting plans allow per-directory PHP configuration. Create a file named php.ini in your WordPress root directory (the same folder as wp-config.php) and add:
max_execution_time = 300
Save the file and test whether the WordPress maximum execution time exceeded error clears on the next attempt at the operation that failed.
Option 3: Add to .htaccess. On Apache servers that allow PHP configuration through .htaccess, add this line to your WordPress .htaccess file:
php_value max_execution_time 300
Not all Apache configurations allow this — if the server uses FastCGI or PHP-FPM, .htaccess PHP directives are ignored and you need to use one of the other methods. If adding this line causes a 500 error, remove it and use the php.ini approach instead. Either way, 300 seconds is a generous limit that resolves the WordPress maximum execution time exceeded error in almost every standard WordPress scenario.
Fix via wp-config.php and WordPress Itself
WordPress includes a built-in way to request a higher execution time limit through the set_time_limit() function, and you can call this from wp-config.php to ensure it applies across all WordPress operations. Open wp-config.php and add this line before “That’s all, stop editing!”:
set_time_limit(300);
This function call requests 300 seconds of execution time from PHP. Whether WordPress receives the full 300 seconds depends on the server’s PHP configuration — if the server enforces an absolute maximum that overrides PHP function calls, the set_time_limit() call is silently ignored and the server limit applies. But on most shared hosting accounts, this call is sufficient to prevent the WordPress maximum execution time exceeded error during standard operations. It takes effect immediately without requiring a server restart and does not require FTP access beyond editing a single file.
Some plugins also include their own execution time increase in their settings — WP All Import, for example, has a configurable execution time limit specifically because bulk imports are the most common context for the WordPress maximum execution time exceeded error during plugin use. Check the settings of any plugin that was running when the error occurred before applying server-level changes — the plugin may offer the fix internally. This is the least disruptive approach when the WordPress maximum execution time exceeded error is isolated to a single plugin operation rather than appearing across multiple contexts.
Identifying the Operation Behind the WordPress Maximum Execution Time Exceeded Error
The error message for the WordPress maximum execution time exceeded error includes the file path where execution was terminated. Reading this path identifies the specific plugin, theme, or WordPress core function that was running when the time limit was hit. A path inside wp-content/plugins/woocommerce/ points to a WooCommerce operation. A path inside wp-includes/ points to a WordPress core process. A path inside a backup plugin’s directory tells you exactly where the backup was when the WordPress maximum execution time exceeded error fired.
This information matters because some operations that hit the WordPress maximum execution time exceeded error can be broken into smaller chunks rather than requiring a permanent increase in the time limit. WooCommerce imports can be done in smaller batch sizes. Thumbnail regeneration can be run in smaller sets using a plugin like Regenerate Thumbnails, which handles the batching automatically. A backup plugin that keeps hitting the WordPress maximum execution time exceeded error might be configurable to use smaller backup chunks or to run at a time of lower server load. These operational adjustments are often better long-term solutions than simply increasing the execution time limit and hoping large operations complete within it.
When the file path in the WordPress maximum execution time exceeded error points to a plugin that is performing what should be a quick operation — not a bulk import or a backup, but a routine page load or an admin action — the plugin itself may have a performance problem. A plugin making hundreds of slow database queries on every request can push total execution time over the limit even when no single operation is obviously heavy. The Query Monitor plugin helps identify these database performance problems by showing query counts and execution times per page load.
When the Time Limit Is Enforced at the Hosting Level
Some hosting providers set an absolute maximum execution time that cannot be overridden by php.ini, .htaccess, or wp-config.php changes. On these plans, the WordPress maximum execution time exceeded error will recur regardless of what values you set in WordPress files, because the hosting environment enforces its own ceiling. This is more common on very low-cost shared hosting plans and on some cloud hosting platforms with strict per-request resource limits.
The Site Health tool in WordPress provides a useful check: go to Tools → Site Health → Info → Server, and look at the PHP Time Limit row. If this shows 30 seconds and your attempts to increase it via php.ini or .htaccess are not reflected, the value is being set by the hosting platform rather than by your configuration files. Contact your hosting provider’s support and ask them to increase the PHP execution time limit for your account. Most reputable hosts offer at least 120 seconds, and many offer 300 seconds or more on plans that advertise WordPress compatibility. If the host cannot increase the limit to at least 120 seconds, the WordPress maximum execution time exceeded error will continue to appear on any site with a modest plugin set and realistic usage patterns, which is a strong signal that the hosting plan is under-resourced for production WordPress.
Preventing the WordPress Maximum Execution Time Exceeded Error
Once the immediate WordPress maximum execution time exceeded error is resolved, a few practices keep it from recurring without constantly pushing against time limits:
- Set a proactive time limit: Rather than waiting for the WordPress maximum execution time exceeded error to appear, set a comfortable limit (120–300 seconds) as part of the initial server configuration for any new WordPress installation. This prevents the error from appearing during routine operations from the start.
- Schedule heavy operations during low-traffic periods: Backups, imports, and thumbnail regeneration tasks that frequently produce the WordPress maximum execution time exceeded error are better run at 3am than mid-afternoon, when competing requests on a shared server consume resources and slow individual processes.
- Use WP-CLI for bulk operations: WP-CLI runs PHP commands from the command line without web server time limits. Operations that consistently hit the WordPress maximum execution time exceeded error through the WordPress admin — like bulk thumbnail regeneration with
wp media regenerate— run without time constraints when executed via WP-CLI. Many managed hosts provide WP-CLI access through their dashboards or SSH. - Keep plugins lean: Each additional active plugin adds to page execution time. A site with 40 active plugins takes measurably longer to execute each request than one with 15, and that accumulated overhead pushes the site closer to the WordPress maximum execution time exceeded error threshold on routine operations.
Our guide on fixing the WordPress memory exhausted error covers the closely related PHP resource limit error that often appears alongside execution time issues — both point to the same underlying problem of a site that has outgrown its hosting plan’s resource allocation. Our guide on how to optimise WordPress performance covers the query optimisation and caching strategies that reduce per-request execution time, making the WordPress maximum execution time exceeded error less likely on complex sites. The PHP configuration documentation covers the full max_execution_time directive including its interaction with set_time_limit() and the hosting-level overrides that affect the WordPress maximum execution time exceeded error in practice. Our guide on WordPress Pagination Fix covers an adjacent issue.
