You’re staring at a white screen — or worse, a half-finished import — and PHP is telling you it ran out of time. This error means a script took longer than your server’s max_execution_time limit (usually 30 seconds) and PHP killed it. It’s one of the most common WordPress errors, and the fix is straightforward once you know where to look.

What Causes Fatal Error: Maximum Execution Time Exceeded?

Low PHP max_execution_time value — Many shared hosts default to 30 seconds, which isn’t enough for heavy operations like importing WooCommerce products or running large database migrations.
A poorly coded plugin or theme — Inefficient database queries or infinite loops in plugin code will eat through any time limit. This is the most common culprit after hosting limits.
Large file imports or media uploads — Importing a 50MB XML file or processing hundreds of images will exceed default limits every time.
Exhausted server resources — If your host is overselling shared resources, even well-written code can time out waiting for CPU or memory allocation.
External API calls that hang — Plugins that call third-party APIs (payment gateways, email services, analytics) without proper timeouts will block execution until PHP kills the process.

How to Fix It

Step 1: Enable Debug Logging to Confirm the Source

Before changing anything, find out exactly which file is causing the timeout. Open wp-config.php in your site root and add these lines above /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reproduce the error, then check wp-content/debug.log via FTP or SSH:

tail -50 wp-content/debug.log

Look for the line that says Maximum execution time exceeded — it will include the exact file path and line number. That tells you whether it’s a plugin, theme, or core issue.

Step 2: Increase max_execution_time in wp-config.php

The right way to do this — add this line to wp-config.php above the /* That's all, stop editing! */ comment:

set_time_limit( 300 );

This sets the limit to 300 seconds (5 minutes) for WordPress specifically. If your host allows it, this takes effect immediately.

Step 3: Set the Value in php.ini or.htaccess

Some hosts ignore set_time_limit(). If Step 2 didn’t work, try these alternatives.

Option A — php.ini (if your host supports custom php.ini files, create or edit one in your WordPress root):

max_execution_time = 300

Option B —.htaccess (Apache servers only, add to the top of your .htaccess file):

php_value max_execution_time 300

Option C —.user.ini (common on hosts running PHP-FPM):

max_execution_time = 300

After making changes, restart PHP or wait a few minutes for .user.ini to take effect.

Step 4: Deactivate the Problem Plugin

If debug.log pointed to a specific plugin, deactivate it. If you can’t access wp-admin, use WP-CLI:

wp plugin deactivate plugin-folder-name

If you don’t have WP-CLI access, rename the plugin folder via FTP:

wp-content/plugins/problem-plugin → wp-content/plugins/problem-plugin-disabled

If you’re not sure which plugin is the issue, deactivate them all and reactivate one at a time:

wp plugin deactivate --all
wp plugin activate plugin-name

Skip this if you want headaches later — don’t just bump the time limit and ignore a plugin that’s running 5-minute queries. That’s technical debt with interest.

Step 5: Contact Your Host

If you’re on shared hosting and none of the above changes stick, your host is overriding them at the server level. Contact support and ask them to increase max_execution_time to 300. If they refuse or cap it at 60 seconds, that’s a sign you’ve outgrown shared hosting.

Kinsta, Cloudways, and SiteGround all default to 300 seconds and let you adjust it further. If you’re running WooCommerce or doing anything beyond a basic blog, you need a host that doesn’t fight you on basic PHP settings.

Step 6: Optimize the Slow Process

For recurring timeouts during imports:

# Split large WXR imports into smaller files
wp import large-file.xml --authors=skip

For WooCommerce product imports, use the built-in batch importer and keep CSV files under 2,000 rows per batch. For database-heavy operations, consider running them via WP-CLI instead of the browser — CLI processes aren’t subject to the same web server timeouts.

Prevention

Set max_execution_time to 300 in wp-config.php as part of your standard WordPress setup. The 30-second default is too low for any site doing real work.
Audit plugins before installing. Check the support forum for timeout complaints. If multiple users report execution time errors, that plugin has a code quality problem.
Run heavy operations via WP-CLI instead of the browser. Imports, bulk edits, and database migrations belong in the terminal, not in wp-admin.
Use a host that gives you control over PHP settings. If you can’t change max_execution_time, you’ll hit this error again every time you install a plugin, run an import, or update WooCommerce.

Last verified: April 2026

Symptoms