If you’ve ever stared at a blank white screen with the message Fatal error: Maximum execution time of 30 seconds exceeded, you know the feeling. Your site is down, your visitors are gone, and you have no clue which script is hanging. This is one of the most common PHP errors on the web, and in 2026 it’s still wrecking WordPress sites, WooCommerce stores and custom APIs.
Here’s the blunt truth: that error isn’t a bug in PHP. It’s a safety brake. PHP kills any script that runs longer than the max_execution_time limit, and by default that’s 30 seconds for web requests and 0 (unlimited) for CLI scripts. When your code hits that wall, the request dies and the fatal error maximum execution time exceeded message shows up.
What Actually Triggers the PHP max_execution_time Fatal Error
The max_execution_time directive only counts CPU time spent by the script itself. That’s a detail most tutorials get wrong. Time spent on database queries, external API calls, file downloads or sleep() calls usually doesn’t count on Linux. So a script can hang for five minutes waiting on a slow MySQL query and still not trigger the error — until the CPU finally starts crunching and blows past the limit.
Typical culprits I’ve seen in the wild:
- Heavy WordPress imports (WP All Import, CSV uploads with thousands of rows).
- WooCommerce product syncs hitting a slow supplier API.
- Image resizing loops using GD or Imagick on huge galleries.
- Badly written recursive functions or infinite while loops.
- Backup plugins zipping gigabytes of files inside a web request.
- Malware or crypto-mining scripts injected into wp-cron.php.
If your site throws this error on a specific admin page, it’s almost always a plugin doing too much work in a single request. If it happens everywhere, suspect a corrupted core file or a hacked installation.
How to Fix It: php_value max_execution_time 600 and Other Real Solutions
The classic fix you’ll find on Stack Overflow is dropping php_value max_execution_time 600 into your .htaccess. That works on Apache with mod_php, but on PHP-FPM — which is what most hosts run in 2026 — it does absolutely nothing except throw a 500 error. That’s a trap worth knowing before you waste an afternoon.
Better options, ranked by how often they actually work:
- php.ini or a custom ini file: set max_execution_time = 600. On cPanel hosts use MultiPHP INI Editor. On Cloudways, RunCloud or GridPane, edit it from the panel.
- wp-config.php: add set_time_limit(600); near the top. This overrides php.ini at runtime and works on FPM.
- .user.ini: place max_execution_time = 600 in your web root. On PHP-FPM with Apache or LiteSpeed, this is respected and survives updates.
- Plugin-level: some plugins like WP All Import let you set the limit per import job, which is cleaner than nuking the whole server.
My take: don’t set 600 globally. That means every broken request can tie up a PHP worker for ten minutes, and on a busy server you’ll run out of workers before you run out of patience. Set it to 120–300 for the specific admin path or the specific script that needs it.
Why Raising the Limit Isn’t Always the Right Answer
Bumping max execution time to 600 seconds is a band-aid. If a script genuinely needs ten minutes of CPU, your architecture is the problem. Long-running jobs belong in a queue, not in a web request.
Realistic alternatives in 2026:
- Move imports and syncs to WP-CLI or a cron job — CLI scripts have no time limit by default.
- Use Action Scheduler (bundled with WooCommerce) to break big tasks into small batches.
- Offload image processing to a service like Cloudinary or imgix.
- Cache the expensive result so you pay the cost once, not on every page load.
I’ve seen agencies set max_execution_time to 3600 to «fix» a WooCommerce sync, and three months later the server was crashing every night because PHP workers were stuck. The error was gone; the underlying problem was worse.
How to Diagnose Which Script Is Timing Out
Before you touch any config, find out what’s actually slow. Guessing wastes more time than measuring.
Quick checklist:
- Check the PHP error log (usually error_log in the site root or via your host panel). The stack trace names the file and line number.
- Enable Query Monitor on WordPress to catch slow queries and slow hooks.
- Run strace -p PID or top -c on the server if you have SSH access — you’ll see which php-fpm process is eating CPU.
- Disable plugins in bulk, then re-enable one by one until the error returns. Boring, but it works.
Once you know the culprit, you can decide: raise the limit for that path, refactor the code, or move it off the web request entirely. That decision matters more than the number you put in php.ini.
Common Mistakes People Make With This Error
Three patterns show up over and over in support tickets:
«I set max_execution_time to 0 and now my site won’t load.»
Zero means unlimited. On a shared host, that lets one bad request hang a worker forever. Never do this on production web requests.
«I changed php.ini but nothing happened.»
You probably edited the wrong php.ini, or your host overrides it with a per-directory config. Check with phpinfo() — the Local Value column is what’s really running.
«It works now, so I’ll leave it.»
If you raised the limit to 600 to make an import finish, that import will eventually grow and hit 600 too. Batch it now, thank yourself later.
The Bottom Line on Fatal Error Maximum Execution Time Exceeded
This error is PHP protecting your server from itself. The fatal error maximum execution time exceeded message means a script ran longer than the max_execution_time directive allows, usually 30 seconds. You can raise it via php.ini, .user.ini or set_time_limit(), and php_value max_execution_time 600 still works on old Apache setups — but on modern PHP-FPM it’s a no-op.
Fix the code or move the work to a queue. Raising the limit is fine as a stopgap, never as a strategy. That’s the difference between a site that stays up and one that keeps showing that ugly white screen to your customers.
