Increase Maximum Execution Time in WordPress

“Maximum execution time of 30 seconds exceeded” means a PHP script ran longer than the max_execution_time setting allows. In WordPress it usually hits during updates, imports and backups.

Below are the ways to increase max_execution_time and how to tell which one your server honors. For a quick fix of the error itself, see Fix Maximum Execution Time Exceeded in WordPress.

Check the Current Value First

Go to Tools > Site Health > Info and open the Server section.

• PHP time limit is the current max_execution_time in seconds.
• PHP SAPI tells you which method will work: apache2handler is Apache mod_php, fpm-fcgi is PHP-FPM, litespeed is LiteSpeed.

Recheck this screen after each change to confirm PHP picked up the new value.

Increase max_execution_time in WordPress

Pick the method that matches your PHP SAPI. The examples use 300 seconds, the limit WordPress core sets for itself during updates.

1. wp-config.php (works on any server)

Add this to wp-config.php, above the /* That's all, stop editing! */ line:

if ( function_exists( 'set_time_limit' ) ) {
	set_time_limit( 300 );
}

Keep the function_exists() check. Since PHP 8, a function blocked with disable_functions counts as undefined, so a bare call crashes the site on hosts that disable it.

2. .user.ini (PHP-FPM and CGI)

On PHP-FPM, the most common setup today, create a .user.ini file next to wp-config.php:

max_execution_time = 300
max_input_time = 300

PHP rereads this file every 5 minutes by default (user_ini.cache_ttl), so the change may not show immediately.

3. .htaccess (Apache mod_php or LiteSpeed)

Back up .htaccess first, then add this line:

php_value max_execution_time 300

This only works with Apache mod_php or LiteSpeed. On Apache with PHP-FPM, php_value is an unknown directive and the site returns a 500 error, so remove it and use .user.ini.

4. php.ini (VPS or dedicated server)

If you control the server, set it in php.ini and restart PHP-FPM or Apache. On shared hosting, use the PHP settings screen in your control panel.

max_execution_time = 300

How max_execution_time Works

The directive caps how many seconds a script may run (30 by default). Calling set_time_limit() changes the limit at runtime and restarts the counter from zero.

On Linux, standard PHP builds count only the script’s own execution time. Database queries and remote API calls don’t count, so a request can run past 30 seconds without this error.

max_input_time is the separate limit for parsing request input such as POST data and uploads. Its default of -1 means it uses max_execution_time. It can’t be changed with set_time_limit() or ini_set(), only in .user.ini, .htaccess or php.ini.

When Raising the PHP Limit Isn’t Enough

If long requests still die after raising the limit, another layer is cutting them off, usually with a 502, 504 or 524 error.

• PHP-FPM’s request_terminate_timeout kills the worker after a set time. It’s off by default, but many hosts enable it.
• Nginx’s fastcgi_read_timeout defaults to 60 seconds.
• Cloudflare returns a 524 if the origin doesn’t respond within 125 seconds on non-Enterprise plans.

Your host has to raise these. For one-off heavy jobs, use WP-CLI instead: on the command line max_execution_time defaults to 0, meaning no limit.

WP-Cron runs as a web request, so web limits apply. For long scheduled tasks, disable WP-Cron and use a real server cron job that runs wp cron event run --due-now.

See also Optimizing WordPress configuration with wp-config.php and the directive reference in the PHP manual.

FAQs

Common questions about the PHP time limit in WordPress: