Skip to content

SiteRepairManual

WordPress repairs run on a throwaway install before they are written down.

Fix “Maximum execution time exceeded” in WordPress

Checked 11 November 2026 · WordPress 7.1.4 · PHP 8.3.6 · MariaDB 10.11.14 · WP-CLI · Read time: 6 minutes

Case file

Symptom
Critical error page, HTTP 500, and a fatal error naming a number of seconds
Cause
One request ran longer than PHP’s max_execution_time — 5 seconds in the reproduction
Fix
Raise max_execution_time to 300 in php.ini, or set_time_limit(300) in wp-config.php
Result
The homepage returns HTTP 200, with the slow task still running

The break · What you need · The diagnosis · The fix · Verify · If that didn’t work · What happened · Where this came from

The break

PHP gives every WordPress request a fixed amount of time. When a request runs longer than that amount, PHP stops it with a fatal error and WordPress shows the critical error page instead of the site. The official list of common errors puts it plainly: a message such as “Maximum execution time of 30 seconds exceeded” means a process is taking too long and timing out, and the fix is to increase the maximum execution time in php.ini.

This guide reproduces the break first. A disposable install ran with max_execution_time at 5 seconds, the kind of low ceiling a cheap host ships with, and a test plugin busy-waited 10 seconds on every page load. The homepage went from HTTP 200 to HTTP 500, and the log named the limit and the file and line where the timer fired.

What you need

The diagnosis

1. Confirm the symptom

Load the homepage and note the status code, not just what the browser shows. In the reproduction, the healthy site returned HTTP 200. With the slow plugin active it returned HTTP 500 with the critical error page:

Output — homepage with the slow plugin active

HTTP 500
<title>WordPress &rsaquo; Error</title>
There has been a critical error on this website.

Key result: HTTP 500 plus the critical error page is the modern form of this failure. The page itself names no number of seconds — the limit is in the log, which is the next step.

2. Read the fatal error in debug.log

Turn on WP_DEBUG and WP_DEBUG_LOG as described in the white screen guide, load the homepage once so the error is written, and read wp-content/debug.log:

Output — wp-content/debug.log

[11-Nov-2026 16:21:06 UTC] PHP Fatal error:  Maximum execution time
of 5 seconds exceeded in
.../wp-content/plugins/srm-slow/srm-slow.php on line 9

5 seconds is the limit that was active when the timer fired — the value the server was started with, not the 30-second PHP default. The file and line are where PHP happened to be when the timer fired, which is the code that was running, not necessarily the code that is slow: here the test plugin was the slow part by design, but on a real site the file in the log is only the starting point for finding what is actually taking the time.

One more thing the log cannot tell you: the timer counts script execution only. The PHP manual says time spent on system calls, stream operations, and database queries is not included in the count — so a script stuck waiting on a network call may not trip this error the same way a busy script does.

Key result: the log gives the limit (5 seconds) and the file and line. That is enough to fix it — the limit is too low for what the site is being asked to do.

Before you raise anything: raising the limit buys time, it does not fix the slow code. The page will still take about 10 seconds to load, and if the same error comes back, the slow process is the problem — not the number. Find the slow code first (see below) before raising the limit again.

The fix

3. Raise max_execution_time in php.ini

This is the fix the official common-errors guide gives. Set the value in php.ini and restart or reload PHP so the change takes effect:

Code — php.ini

max_execution_time = 300

On the test server the same change was made by restarting PHP with max_execution_time=300, which is the php.ini-edit equivalent. The homepage returned HTTP 200 in about 10 seconds — the slow task finishing, not the site being fast. A slow page that loads is the fix working.

4. Or set the limit in wp-config.php

If you cannot edit php.ini, add this line to wp-config.php, before the line that reads /* That's all, stop editing! Happy blogging. */:

Code — wp-config.php

set_time_limit( 300 );

The PHP manual says set_time_limit() restarts the timeout counter from zero. In the reproduction the homepage returned HTTP 200 in 10.3 seconds with the slow plugin still active, which proves the new limit — not the plugin being switched off — is what fixed it. The test plugin was deactivated afterwards and the homepage stayed at HTTP 200.

Trap: the call has to run before the slow code does. wp-config.php loads before plugins and themes, so the line works there. Putting it in a theme or plugin file that loads after the slow code runs does not. If the line has no effect at all, your host is overriding it — ask the host to raise max_execution_time instead.

Verify the site is back

Load the homepage again and check the status code — and the time it takes. In the reproduction both fixes returned HTTP 200 with the slow plugin still active, and the page took about 10 seconds to load because the test task takes 10 seconds. That slowness is the task, not the fix failing.

Output — homepage after raising the limit

HTTP 200
<title>SRM Test</title>
StepHomepage status
Healthy siteHTTP 200
Slow task, limit 5 secondsHTTP 500 — critical error page
After set_time_limit(300)HTTP 200 in 10.3 seconds
After max_execution_time 300HTTP 200 in about 10 seconds

If that didn’t work

Find the slow code

Raising the limit is a valid immediate fix and a poor permanent one. A normal page renders in well under 30 seconds. If the error comes back, the file and line in the debug log are the starting point: deactivate plugins one by one from there, and switch to a default theme to rule the theme out, as the official common-errors guide describes for timeouts.

A task that never finishes is not a limit problem

If a 300-second limit still trips, the task itself is the problem — an import, a backup, or a thumbnail regeneration that never finishes will not be fixed by a bigger number. Split the work into smaller batches, or run it outside a web request. And if the host will not raise the limit at all, that is a hosting decision, not a WordPress one: the fix is a host that allows the time the site needs.

What happened

One request needed 10 seconds and the site only allowed 5, so PHP stopped it with a fatal error and the homepage returned HTTP 500. The debug log gave the limit in seconds, max_execution_time was raised to 300 in php.ini — and separately set_time_limit(300) was verified in wp-config.php — and the homepage returned HTTP 200 with the same slow plugin still active.

Where this came from