How to Fix the max_execution_time Error in WordPress

The max_execution_time error in WordPress occurs when a PHP script exceeds the maximum execution duration configured at the server level. PHP terminates the script and returns a fatal error, which WordPress surfaces as a white screen, a timeout notice, or an explicit "Maximum execution time exceeded" message.

By default, most shared hosting environments enforce a limit of 30 seconds. Operations such as importing a WooCommerce product CSV, running a full-site backup, or installing a large plugin bundle can easily breach this ceiling. Raising the limit — through php.ini, .htaccess, wp-config.php, or the WordPress plugin layer — resolves the error without compromising server stability when done correctly.

Understanding Why the Limit Exists and When It Becomes a Problem

PHP's max_execution_time directive is a resource-protection mechanism, not an arbitrary restriction. It prevents a runaway script from monopolizing CPU time on a shared process pool, which is especially critical on multi-tenant infrastructure.

The limit becomes a genuine obstacle in these scenarios:

• Large database imports or exports via phpMyAdmin or WP-CLI that process thousands of rows
• Plugin or theme installations that unzip archives exceeding 50 MB
• WooCommerce bulk operations — price updates, inventory syncs, order exports
• Full-site migrations using tools like Duplicator or All-in-One WP Migration
• Scheduled cron jobs that aggregate data from external APIs
• Image optimization plugins processing hundreds of unoptimized uploads in a single batch

A critical nuance most guides omit: max_execution_time measures CPU time consumed by the PHP process, not wall-clock time. On a heavily loaded server, a script can run for 90 real-world seconds while consuming only 28 seconds of CPU time and never trigger the limit. Conversely, a CPU-intensive loop hits the limit faster than expected. This distinction matters when diagnosing intermittent timeouts.

How to Verify Your Current max_execution_time Value

Before changing anything, confirm the active limit. Create a temporary file in your WordPress root — never leave it publicly accessible after testing:

<?php
phpinfo();

Upload it as phpinfo-test.php, visit https://yourdomain.com/phpinfo-test.php, and search for max_execution_time in the output. Delete the file immediately after checking.

Alternatively, use WP-CLI from SSH:

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

This returns the value currently active for WordPress requests, which may differ from the server's global php.ini if a per-directory override is already in place.

Method 1: Edit the php.ini File (Most Reliable)

Modifying php.ini is the most authoritative method because it sets the directive at the PHP interpreter level, overriding nothing and being overridden by nothing below it in the configuration hierarchy — unless a later ini_set() call supersedes it at runtime.

Step 1: Locate the Correct php.ini File

This is where most administrators make a mistake. PHP can load multiple .ini files depending on the SAPI (Server API) in use:

• CLI SAPI (/etc/php/8.x/cli/php.ini) — used by WP-CLI and cron jobs
• FPM SAPI (/etc/php/8.x/fpm/php.ini) — used by Nginx + PHP-FPM stacks
• Apache mod_php (/etc/php/8.x/apache2/php.ini) — used by Apache with the PHP module

Editing the CLI php.ini will fix WP-CLI timeouts but will not affect browser-triggered requests. Always identify the correct SAPI first:

php -i | grep "Loaded Configuration File"

For web requests, check the phpinfo() output under Loaded Configuration File.

Step 2: Edit or Create php.ini in the Web Root

On shared hosting where you lack root access, you can place a user-level php.ini in your site's root directory (public_html). Access it via cPanel File Manager, FTP, or SSH:

nano ~/public_html/php.ini

Add or update the directive:

max_execution_time = 300

300 seconds (5 minutes) is sufficient for most operations. For extremely large migrations, consider 600 seconds temporarily, then revert once the task completes.

Step 3: Verify the Change Took Effect

After saving, re-run the phpinfo() check or the WP-CLI command from earlier. If the value has not changed, your host may be enforcing a hard limit via max_execution_time in a server-level php.ini that supersedes your user-level file. In that case, proceed to Method 4.

Step 4: Restart PHP-FPM (VPS and Dedicated Servers)

On a VPS or dedicated server where you control the environment, a PHP-FPM restart is required for the change to propagate to web requests:

sudo systemctl restart php8.2-fpm

Replace php8.2-fpm with your installed PHP version. Apache with mod_php requires an Apache reload instead:

sudo systemctl reload apache2

Method 2: Edit the .htaccess File (Apache Only)

The .htaccess method works exclusively on Apache servers where AllowOverride permits PHP configuration directives. It does not work on Nginx, LiteSpeed with certain configurations, or any stack where PHP runs as FastCGI/FPM with AllowOverride None.

Step 1: Reveal and Access the .htaccess File

The .htaccess file is hidden by default. In cPanel File Manager, click Settings in the top-right corner and enable Show Hidden Files (dotfiles). The file lives in public_html.

Via SSH:

nano ~/public_html/.htaccess

Step 2: Add the PHP Directive

Insert the following line. Position matters — place it outside any <IfModule> block to ensure it applies globally:

php_value max_execution_time 300

If your server runs PHP-FPM (identifiable by PHP/x.x.x (fpm-fcgi) in phpinfo()), this directive will cause a 500 Internal Server Error because php_value is not valid in that context. Use php_admin_value only if the host explicitly permits it, or switch to Method 1.

Step 3: Test for 500 Errors

After saving, immediately load your homepage. A 500 error means the directive is incompatible with your server configuration. Remove the line and use an alternative method.

Method 3: Edit wp-config.php Using set_time_limit()

The set_time_limit() function resets the execution timer from the point it is called. This is a PHP runtime call, not a configuration directive, which means it works regardless of whether the server allows php.ini or .htaccess overrides — as long as PHP's disable_functions list does not include it.

Step 1: Locate wp-config.php

The file sits in the WordPress installation root, one level above public_html on some server configurations, or directly inside it on others.

find ~/public_html -maxdepth 2 -name "wp-config.php"

Step 2: Add the Directive

Open wp-config.php and add the following line before the /* That's all, stop editing! Happy publishing. */ comment:

set_time_limit(300);

Calling set_time_limit(0) disables the limit entirely for that request. Use this only as a temporary diagnostic measure — never in production — because it removes the safety net against infinite loops.

Important caveat: set_time_limit() affects only the current script execution. It does not change the server-wide PHP configuration. If a plugin internally spawns a subprocess or makes a blocking HTTP request, that subprocess is not covered by this call.

Method 4: Use a WordPress Plugin

For users who prefer not to edit server files directly, several plugins expose PHP configuration values through the WordPress admin interface. This approach is appropriate for non-technical site owners on managed hosting.

Recommended options:

• WP Maximum Execution Time Exceeded — specifically targets this error and attempts multiple override methods
• PHP Settings — provides a dashboard view of active PHP directives and allows safe overrides where the host permits

To install: navigate to Plugins > Add New in the WordPress dashboard, search for the plugin name, install, and activate. Follow the plugin's settings page to set your desired execution time.

Limitation: Plugins can only call set_time_limit() or ini_set() at runtime. If the host has locked max_execution_time via open_basedir restrictions or a hardcoded server configuration, the plugin will silently fail to increase the limit. Always verify the change using phpinfo() after activating.

Method 5: Contact Your Hosting Provider

If none of the above methods produce a verified change in phpinfo() output, the limit is enforced at the server level by your host. This is common on entry-level shared hosting plans where the provider sets a hard ceiling to protect shared resources.

When contacting support, provide:

• The exact error message and the WordPress action that triggers it
• The current max_execution_time value from phpinfo()
• The value you need (e.g., 300 seconds) and the reason (e.g., large WooCommerce import)

Reputable hosts will either adjust the limit for your account or point you to a control panel option (such as a PHP selector in cPanel) where you can configure it yourself.

Comparison of All Five Methods

Diagnosing Persistent Timeouts After Increasing the Limit

If you have confirmed the new limit is active in phpinfo() but the error persists, the bottleneck is likely not max_execution_time. Consider these alternative causes:

FastCGI or Nginx timeout directives — Nginx has its own fastcgi_read_timeout directive, separate from PHP:

fastcgi_read_timeout 300;

This must be set in the Nginx server block and requires an Nginx reload.

Apache TimeOut directive — Apache's own connection timeout can terminate a request before PHP's limit is reached:

TimeOut 300

PHP-FPM request_terminate_timeout — In PHP-FPM pool configuration (/etc/php/8.x/fpm/pool.d/www.conf), this directive independently kills worker processes:

request_terminate_timeout = 300

MySQL wait_timeout and interactive_timeout — Long-running database queries can cause the MySQL connection to drop mid-execution, which PHP surfaces as a script failure rather than a database error. Check with:

SHOW VARIABLES LIKE '%timeout%';

WooCommerce or plugin-level timeouts — Some plugins implement their own internal timeout logic using PHP's set_time_limit() with a lower value, which resets the counter and can override your configuration.

Performance Considerations and Best Practices

Increasing max_execution_time is a targeted fix, not a permanent architectural solution. If a specific operation routinely exceeds 30–60 seconds, the underlying process should be optimized or restructured:

• Batch processing: Break large imports into smaller chunks using AJAX-based chunking (as WP All Import does natively) rather than processing everything in a single HTTP request
• Background processing: Use WP-Cron or a proper task queue (Action Scheduler, used by WooCommerce) to move long-running work off the web request lifecycle
• WP-CLI for bulk operations: CLI execution is not subject to web server timeouts and is the correct tool for database imports, search-replace operations, and bulk media processing
• Optimize slow queries: Use the Query Monitor plugin to identify database queries consuming disproportionate execution time
• Upgrade hosting tier: If your workload consistently requires extended execution times, a VPS with cPanel gives you full control over PHP configuration and dedicated resources that do not compete with other tenants

For high-compute workloads such as AI-driven product recommendations or large-scale image processing pipelines, GPU hosting offloads the intensive computation entirely from the PHP layer.

Practical Decision Checklist

Use this checklist before and after applying any fix:

• Confirm the current max_execution_time value via phpinfo() or WP-CLI before making changes
• Identify your server stack (Apache + mod_php, Apache + FPM, Nginx + FPM) before choosing a method
• Apply only one method at a time — stacking php.ini, .htaccess, and wp-config.php changes simultaneously makes debugging impossible
• After applying a change, re-verify the active value in phpinfo() — do not assume the change worked
• Test by reproducing the original failing action, not just by loading the homepage
• If the error is resolved, consider whether the underlying operation can be optimized to run within the original limit
• Set a calendar reminder to revert any temporary limit increases (e.g., set_time_limit(0)) after the one-off task is complete
• On shared hosting, document what the host confirmed as the maximum allowable value for your plan
• If timeouts persist after confirming the PHP limit is raised, audit Nginx fastcgi_read_timeout, Apache TimeOut, and PHP-FPM request_terminate_timeout independently

FAQ

What is the safest value to set for max_execution_time in WordPress?

300 seconds (5 minutes) covers the vast majority of resource-intensive WordPress operations including large plugin installations, WooCommerce imports, and theme updates. Values above 600 seconds should be treated as temporary and reverted after the specific task completes.

Why does my max_execution_time change not appear in phpinfo() after editing php.ini?

You are most likely editing the wrong php.ini file. PHP loads different configuration files for CLI, Apache mod_php, and PHP-FPM. Run php -i | grep "Loaded Configuration File" for CLI and check the Loaded Configuration File row in a browser-accessible phpinfo() page to identify the correct file for web requests.

Does increasing max_execution_time affect all users on my server?

On a shared server, editing a user-level php.ini in your web root affects only your account. Editing the global server php.ini (which requires root access) affects all PHP processes on that server. On a dedicated server, you control the global configuration and bear full responsibility for its impact.

Will the .htaccess method work on an Nginx server?

No. The .htaccess file is an Apache-specific mechanism. Nginx does not process .htaccess files. On Nginx + PHP-FPM stacks, you must edit the PHP-FPM pool configuration or the server-level php.ini, both of which require SSH access.

Can a WordPress plugin permanently increase max_execution_time?

No. Plugins execute within the PHP runtime and can only call set_time_limit() or ini_set(), which affect the current request only. They cannot write to php.ini or persist configuration changes across requests. For a permanent increase, you must modify php.ini, .htaccess, or a PHP-FPM pool configuration file at the server level.