WordPress maximum execution time exceeded: how to fix it

The error message is direct: Fatal error: Maximum execution time of 30 seconds exceeded in /path/to/file.php on line 123 . PHP enforces a time limit on every script execution, and the script ran past it. PHP killed the process to prevent a single request from monopolizing server resources indefinitely.

This error appears most often during operations that process large amounts of data – importing content, exporting databases, regenerating thumbnails, running plugin migrations, updating WooCommerce product catalogs, or installing large plugins. It can also appear on normal page loads if a plugin runs an expensive operation (a complex database query, an external API call that hangs, or a recursive function that takes too long to complete).

The immediate fix is simple – increase the time limit. But understanding why the limit exists and which operations legitimately need more time helps you fix the root cause rather than just raising the ceiling.

How PHP execution time works#

Every time a visitor loads a page, PHP starts processing the request. The max_execution_time setting defines how many seconds PHP is allowed to run before it is forcibly terminated. The default in most PHP installations is 30 seconds.

This limit exists to protect the server. Without it, a single buggy script could run forever, consuming a PHP-FPM worker and memory indefinitely. On a shared hosting server with limited PHP workers, one infinite loop would eventually consume all available workers and take every site on the server offline.

The timer starts when PHP begins executing and counts only CPU time spent by the PHP process. Time spent waiting for external responses (database queries, HTTP requests to external APIs) does not count toward the limit on most systems. This means a script that runs for 60 seconds but spends 50 of those seconds waiting for a database response may or may not exceed a 30-second limit depending on the operating system.

On Linux (which includes virtually all WordPress hosting), the max_execution_time tracks wall clock time, not CPU time. This is an important distinction – a script waiting 25 seconds for a slow API response and then doing 10 seconds of processing will exceed a 30-second limit even though the PHP process only did 10 seconds of actual work.

Where the limit is set#

Like PHP memory limits, execution time limits can be set in multiple places with a priority hierarchy:

php.ini (server level):

max_execution_time = 30

PHP-FPM pool configuration:

php_admin_value[max_execution_time] = 120

Settings defined with php_admin_value in the FPM pool cannot be overridden by WordPress or by ini_set() in PHP code.

.user.ini (per-directory):

max_execution_time = 120

WordPress code (runtime override):

set_time_limit(120);

or:

ini_set('max_execution_time', 120);

These runtime overrides only work if the PHP-FPM pool does not use php_admin_value to lock the setting. On managed hosting, the pool configuration typically takes precedence.

On Hostney, max_execution_time is configurable per site through Hosting > PHP Manager > Variables. The change applies immediately to the site’s PHP container.

Common triggers#

Plugin and theme updates

WordPress downloads a zip file, extracts it, moves files, and runs upgrade routines. For large plugins (WooCommerce, Elementor, Yoast) or themes with many template files, the extraction and file operations can exceed 30 seconds, especially on servers with slower disk I/O.

Content imports

The WordPress importer reads an XML file (WXR format), parses it, creates posts, downloads and attaches media files, and assigns taxonomies. A large import with thousands of posts and hundreds of media files can run for minutes.

Database operations

Plugins that run migrations, search-replace operations, or database schema changes may process every row in a large table. A WooCommerce product migration touching 50,000 rows with metadata can easily exceed any reasonable timeout.

Image regeneration

After switching themes, WordPress needs to regenerate thumbnails for all existing images at the new theme’s dimensions. Processing thousands of high-resolution images is inherently slow.

External API calls

A plugin that synchronizes data with an external service (importing products from a feed, syncing orders with a CRM, pushing data to a marketing platform) may make hundreds of sequential API calls. If each call takes 500ms and there are 200 items to sync, the total time is 100 seconds.

Backup creation

Backup plugins that create a complete site archive (files + database) need to read every file and compress the database dump. On large sites this can take several minutes.

How to fix the error#

Step 1: Increase the execution time

The immediate fix is raising the limit. 120 seconds (2 minutes) is a reasonable starting point for admin operations:

On Hostney: Go to Hosting > PHP Manager > Variables and increase max_execution_time . The change takes effect immediately.

Via wp-config.php:

set_time_limit(120);

Add this before the line that says “That’s all, stop editing.” This calls PHP’s set_time_limit() function on every request. Note that this only works if the hosting environment allows runtime overrides.

Via .user.ini (create in WordPress root if it does not exist):

max_execution_time = 120

After making the change, verify it took effect:

wp eval "echo ini_get('max_execution_time');"

If the value did not change, the PHP-FPM pool configuration is overriding your setting. Contact your host.

Step 2: Use WP-CLI for long operations

WP-CLI runs in PHP’s CLI SAPI (Server Application Programming Interface), which has a separate configuration from the web SAPI. The CLI SAPI typically has max_execution_time set to 0 (unlimited) by default. This means operations that timeout in the browser work fine via WP-CLI:

# Import content without timeout
wp import large-export.xml --authors=create

# Regenerate all thumbnails without timeout
wp media regenerate --yes

# Search and replace across the database
wp search-replace 'old-domain.com' 'new-domain.com' --all-tables

# Run a plugin's migration command
wp wc update

WP-CLI also does not have Nginx’s proxy_read_timeout or fastcgi_read_timeout limits, so there are no web server timeouts to worry about either.

If you do not have SSH access but have terminal access through a hosting control panel, WP-CLI is usually available through the terminal interface. On Hostney, SSH access is available on all plans.

Step 3: Process in batches

If the operation that times out is something you control (custom code, a configurable plugin), break it into smaller batches. Instead of processing 10,000 items in one request, process 100 items per request across 100 requests.

Most well-designed WordPress plugins handle batching automatically. WooCommerce’s database update process, for example, runs in batches and resumes where it left off. If a plugin’s migration process times out, check the plugin’s documentation for a batch size setting or a WP-CLI command that handles batching.

For custom code, use WordPress’s built-in batch processing via cron:

function process_batch() {
    $items = get_option('items_to_process', array());
    $batch = array_splice($items, 0, 100);

    foreach ($batch as $item) {
        // Process item
    }

    update_option('items_to_process', $items);

    if (!empty($items)) {
        wp_schedule_single_event(time() + 10, 'process_next_batch');
    }
}
add_action('process_next_batch', 'process_batch');

This processes 100 items, saves progress, and schedules the next batch. Each batch runs in its own PHP request with a fresh execution timer.

Step 4: Identify the slow operation

If the timeout happens on normal page loads (not during imports or admin operations), something is taking too long on every request. This is a performance problem, not a timeout configuration problem.

Enable the PHP slow log to identify which functions are taking the most time. On Hostney, the slow log is at ~/.logs/{your-domain}-php.slow.log . If a function consistently appears in the slow log, that is the operation you need to optimize.

Common causes of slow page loads:

• Unoptimized database queries. A plugin running  SELECT *  on a large table without an index. Install Query Monitor to identify slow queries.
• External API calls on every page load. A plugin checking a remote API on every request instead of caching the result. See WordPress cURL error 28: connection timed out for diagnosing slow external calls.
• File system operations. A plugin scanning directories on every request (some security plugins do this). On sites with thousands of files, directory scanning is slow.

The difference between PHP timeout and web server timeout#

There are actually three timeout limits that can kill a long-running request:

PHP max_execution_time – kills the PHP script after X seconds. This is the “Maximum execution time exceeded” error.

Nginx fastcgi_read_timeout – kills the connection between Nginx and PHP-FPM if Nginx does not receive a response within X seconds. This produces a 504 Gateway Timeout error.

PHP-FPM request_terminate_timeout – kills the PHP worker process if it runs longer than X seconds. This produces a 502 Bad Gateway error.

Increasing max_execution_time alone does not help if the web server timeout is lower. If you set PHP to allow 300 seconds but Nginx times out at 60, you get a 504 at 60 seconds. All three limits need to accommodate the operation’s duration.

On Hostney, the PHP-FPM request_terminate_timeout is automatically set slightly higher than max_execution_time , so the PHP timeout always triggers before the worker kill. Nginx timeouts are configured for WordPress compatibility.

When increasing the timeout is wrong#

If a normal front-end page load exceeds 30 seconds, the answer is not to increase the timeout. Something is fundamentally broken – a plugin with a performance bug, a database table missing an index, or an external service that is not responding.

Signs that you should fix the code rather than raise the limit:

• The timeout happens on front-end pages, not just admin operations
• The timeout happens on every page load, not just specific operations
• Increasing the limit just delays the error rather than preventing it
• Memory usage grows alongside execution time (indicating a loop or leak)

A WordPress front-end page should load in under 5 seconds. If it needs 30+ seconds, investigate with Query Monitor, the PHP slow log, or by deactivating plugins one at a time.

How Hostney handles execution time#

Configurable per site. The max_execution_time is adjustable through Hosting > PHP Manager > Variables. Changes apply immediately to the site’s PHP container without affecting other sites.

Container isolation. A long-running script on one site does not consume PHP workers for other sites. If a WooCommerce import runs for 2 minutes on one site, other sites on the same server continue processing requests normally with their own isolated worker pool.

SSH and WP-CLI access. For operations that inherently need long execution times (imports, migrations, bulk updates), SSH access and WP-CLI are available on all plans. Running these operations via WP-CLI bypasses both the PHP web timeout and the Nginx timeout entirely.

Per-site slow logs. Each site has its own PHP slow log that captures functions exceeding a configurable threshold. This makes it straightforward to identify which operations are consuming the most time without sifting through a shared server log.

Summary#

“Maximum execution time exceeded” means a PHP script ran longer than the configured limit allows. The immediate fix is increasing max_execution_time in PHP configuration. For operations that inherently need long execution times (imports, exports, migrations, thumbnail regeneration), use WP-CLI instead of the browser – it has no web timeout.

If the timeout happens during normal page loads rather than admin operations, the problem is a slow operation that needs optimization, not a higher timeout. Check the PHP slow log and Query Monitor to identify the bottleneck. For a complete reference of WordPress errors and their quick fixes, see How to fix the most common WordPress errors.