Troubleshooting guide · website-errors · Published 2026-08-16 · 3 min read
PHP max execution time and fatal timeout errors
PHP max execution time explained: the fatal timeout error, memory and I/O causes, and safe ways to raise or avoid the limit.
- ·The fatal timeout error
- ·Why the limit trips
- ·Raise or fix it
What the limit does
max_execution_time is a PHP setting that stops a script when it has been actively running for longer than the limit. On a typical server it is set to 30 or 60 seconds. When a script trips it, PHP throws the fatal error:
Fatal error: Maximum execution time of 30 seconds exceededThe counting starts when the script begins, and by default it only counts time the script spends actively running, not the time it waits on I/O such as a slow database query or a remote call. On most shared hosts the setting is a low default and is meant to protect the server, so raising it blindly only masks a script that is doing too much.
Why a script trips the limit
- A long-running third-party call. Sending an email, hitting an external API or fetching a large remote file makes the script wait, and with
ignore_user_abortoff the timeout can fire. - A heavy loop or import. Bulk content, image processing or a report over a large dataset keeps the CPU busy past the limit.
- A slow database query. A query without an index can run for longer than the PHP budget even though PHP itself is idle waiting on it.
- A wrong setting at runtime.
set_time_limit(0)disables the limit for that request; if code calls it globally, an otherwise healthy site loses its guard.
How to raise or fix it
Raise the limit for one script, not the whole server. In the file that needs more time, at the top:
set_time_limit(120);Prefer a config change to a global disable.
php.ini:max_execution_time = 90.htaccess(mod_php):php_value max_execution_time 90php.iniper vhost or.user.ini: same key for a single directory
Chase the actual cost. If one page exceeds 30 seconds, find what it waits on. Turn on query logging to find the slow SQL, cache the expensive third-party result, process imports in batches, and make image work asynchronous. Raising the limit from 30 to 300 hides a query that should take milliseconds.
Slow queries are a far more common timeout cause than PHP itself.| Case | Better fix than raising the limit |
|---|---|
| Slow database query | Add an index, cache the result |
| Large import | Batch rows, run in the background |
| External API wait | Cache the response, use a job queue |
| Image processing | Queue the job, resize off the request |
When a persistent limit is worth keeping
A long max_execution_time on a public host lets one misbehaving request tie up a worker. If you genuinely need many seconds, prefer the asynchronous path: a button uploads the job and the work runs in a queued worker, so the browser returns quickly and the site stays responsive. That course keeps the guard while removing the user-facing wait. For a memory-related cousin of the same class see WordPress memory limit, and for the fatal errors that bring a whole site down see the PHP fatal guide. A full disk can also tip a borderline request over the edge, so check disk space at the same time.