Error fix · Developer errors

PHP "Maximum execution time of 30 seconds exceeded" Fix

Fix PHP's "Maximum execution time exceeded" fatal error: raise max_execution_time where it really applies, and find out why the script is slow in the first place.

Error messageFatal error: Maximum execution time of 30 seconds exceeded

By SiteDownCheck Editorial · Updated October 14, 2026 · 4 min read

This fatal error means one PHP request ran longer than max_execution_time allows, so the engine stopped it. The full message names the file and line where PHP was when the timer expired:

PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /var/www/html/import.php on line 88

The number is whatever limit is in effect. The default is 30 seconds, but hosts often set 60, 120 or 300. Remember that the line in the message is just where the script happened to be, not necessarily the slow part.

What the timer actually measures

On Linux and other non-Windows systems, the PHP manual says the limit only counts time the script itself spends executing. Time spent in system calls, stream operations, database queries and similar waits is not included. On Windows the measured time is real (wall-clock) time. That explains two common puzzles: a script waiting 90 seconds on a slow API may not trigger the error on Linux, and a CPU-heavy loop will trigger it quickly.

The command line is different: the CLI normally has no limit (max_execution_time is 0), so a cron script never shows this error unless the code calls set_time_limit() itself. Confirm with php -i | grep max_execution_time.

Causes, most likely first

  1. A long job running inside a web request: imports, exports, report generation, image batches, backups, bulk emails.
  2. A loop that never ends or does far more work than expected, often from unbounded pagination or a recursion bug.
  3. Heavy CPU work in PHP, such as parsing a large XML or CSV in memory.
  4. A slow query or API call repeated per item (the N+1 pattern), which stacks up even though each call is fast.
  5. A low limit set by the host that your code never changed.

Step 1: see which limit applies

The limit can come from php.ini, a pool config, .user.ini, .htaccess (only for mod_php) or a ini_set() call. Ask PHP itself, from a web request rather than the CLI:

<?php echo ini_get('max_execution_time');

Do not leave that file on a public server. For the FPM side, also check the pool config for request_terminate_timeout, which kills a worker regardless of PHP's own timer.

Step 2: raise it, narrowly

For one script, set it at the top of that script:

set_time_limit(300);   // restart the timer at 300 seconds

Calling set_time_limit() restarts the counter from zero at the moment you call it. For a site-wide change use php.ini:

max_execution_time = 120

Then reload PHP-FPM (sudo systemctl reload php8.2-fpm). On shared hosting, a .user.ini file with the same line often works under PHP-FPM or CGI.

In WordPress, a plugin or update that times out is usually better fixed by raising the limit temporarily in php.ini than by editing core files.

Step 3: raise the other timers too

PHP is rarely the only clock. If you raise PHP to 300 seconds but the web server gives up at 60, the browser sees a gateway error instead:

  • nginx: fastcgi_read_timeout 300s; in the PHP location, otherwise you get a 504. See nginx upstream timed out and nginx 502 and 504 timeout tuning.
  • PHP-FPM: request_terminate_timeout defaults to 0 (off), but many hosts set it.
  • Apache with mod_php or proxy_fcgi: the Timeout and ProxyTimeout directives.
  • CDN or load balancer: Cloudflare, for example, returns error 524 when the origin takes too long.

Step 4: stop doing the work in the request

If a task needs minutes, a bigger timeout is a patch. Better options:

  • Move it to a queue or a scheduled job and show the user a progress page.
  • Process in batches of a few hundred rows per request, saving a cursor between calls.
  • Add an index or cache for the slow query; in PHP-FPM you can find slow spots with request_slowlog_timeout = 5s and a slowlog path, which dumps a backtrace for long requests.
  • Run long jobs from cron on the CLI, where the limit is off. Watch them with a cron monitor so a silent failure is noticed.

Verify the fix

Run the failing action again and time it with time curl -s -o /dev/null https://example.com/slow-endpoint. Check the PHP error log for the message disappearing, and put the endpoint under an uptime monitor so slowdowns are caught early.

Next steps

FAQ

Is max_execution_time wall-clock time?

Not on Linux. According to the PHP manual, waits such as database queries, system calls and stream operations are not counted; on Windows the time is real time.

Why does the error never appear in my cron job?

The PHP command line has no execution limit by default. Check php -i | grep max_execution_time with the same PHP binary your cron job uses.

Does set_time_limit(0) remove the limit?

Yes, it disables the PHP timer for that request. Web server, FPM and proxy timeouts still apply, and an endless script will hold a worker.

Why did I get a 504 instead of this error?

A proxy timeout fired before PHP's. Raise the matching timeout in nginx, Apache or the CDN.

Get notified when this fix updates

Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.