Guide Errors & Troubleshooting

How to fix "maximum execution time exceeded"

A script ran for longer than PHP allows and was stopped mid-task — here is how to give it more time, or find out why it needed it.

Updated 6 min read Intermediate

The exact message is usually: "Fatal error: Maximum execution time of 30 seconds exceeded". It means a PHP script ran for longer than the configured limit and was forcibly stopped. This is a safeguard against a script that has hung or is looping indefinitely, consuming a server process forever — it stops that from happening by cutting off any single request after a fixed amount of time.

The 30-second figure in the message is a common default, not a universal one, and it applies per request, not to the site as a whole. A page that itself does very little will never come close to it; the error only ever appears on something that is doing more work than it has time to finish.

The causes, in the order worth checking

1. A large import, export, or bulk operation run through a normal page

This is the most common cause by far. Migrating a large amount of data, generating a big report, or running a bulk update — anything working through hundreds or thousands of records in one pass — will often need more time than a web request is designed to allow, even when nothing about it is actually broken.

The correct fix for a genuinely large one-off task is to run it from the command line, where the default is typically no time limit at all, or to break it into smaller batches processed over several requests rather than one long one. WP-CLI, where available, runs WordPress import and maintenance commands this way by default.

2. A slow database query

An unindexed table or a query written against a much larger dataset than it was designed for can take far longer than expected on its own, independent of anything else the page is doing. If the timeout correlates with a specific action rather than the whole site being generally slow, a single slow query behind that one action is worth checking before anything else.

3. A slow external service the site depends on

A page that waits on a remote API — a payment gateway, a shipping calculator, a social feed — is at the mercy of how quickly that service responds. If the third party is degraded, a request that normally completes in under a second can hang until it eats the entire available execution time. Check whether affected pages share a dependency on the same outside service.

4. An infinite or near-infinite loop in code

A loop with a condition that never becomes false, or a recursive function without a proper base case, will run until something external stops it — which is exactly what this limit is for. If raising the limit only delays the same error rather than resolving it, this is the explanation to look for, and it needs a code fix rather than a bigger number.

Raising the limit for a specific task

In a plain PHP script, near the top of the file:

set_time_limit(300); // seconds

In WordPress, this is usually set in php.ini or your control panel's PHP settings rather than in wp-config.php, since it needs to apply before WordPress itself loads:

max_execution_time = 300

Most control panels expose this directly under PHP configuration for the site, which is the more reliable place to change it if your hosting doesn't allow a custom php.ini per account.

Check for a separate proxy or gateway timeout too

If the site sits behind a CDN or reverse proxy, that layer often enforces its own timeout independently of PHP's. Raising max_execution_time alone will not help if the proxy in front of the server gives up first — see fixing a 504 Gateway Timeout if that's the layer actually cutting the request short.

Finding exactly what was running when it happened

The error log section of your control panel records the file and line where execution stopped, which usually points straight at the specific loop, query, or API call responsible rather than leaving you to guess from the page alone.

If a longer limit doesn't fix it

Tell us what action triggers the error and roughly how long it runs before failing. That's usually enough for support to tell you whether you're dealing with a task that genuinely needs to run outside a normal web request, or a script that's taking far longer than it reasonably should.

Frequently asked questions

Is it safe to just set max_execution_time very high?

For a one-off task such as a large import, a temporary increase is reasonable. Setting it permanently very high across the whole site is not — a genuinely stuck script would then tie up a worker process for far longer before anything intervenes, which can make a minor bug into a resource problem. Raise it for the specific task, not as a permanent default.

Why does the command line version of my site not have this problem?

PHP run from the command line defaults to no execution time limit at all, on the reasoning that a script started deliberately from a terminal is expected to run as long as it needs to. That is exactly why long-running jobs — imports, exports, backups — belong there rather than behind a web request.

Related reading