PHP Errors

PHP Maximum Execution Time Exceeded

Intermediate Risk: medium

Last reviewed July 19, 2026

Hosting access often needed Database access usually not needed

Graphic options · pick what to keep

serverRack

decisionTree

requestTimeline

browserMock

Direct answer

Maximum execution time exceeded means a PHP script ran longer than max_execution_time allows—raise the host limit modestly for legitimate heavy tasks, then find and fix the slow plugin, import, cron job, or external API call instead of setting infinite timeouts.

WordPress sites often show this as a fatal in logs, a blank or partial page, or a gateway timeout when PHP never finishes. Backup plugins, imports, builders, and runaway cron are common culprits. This guide explains how max_execution_time relates to set_time_limit, proxy timeouts, and slow MySQL so you fix the slow work—not just the clock.

Intermediate

What the error means

PHP starts a per-request timer controlled by max_execution_time in php.ini (or MultiPHP INI). When the script exceeds that budget, PHP terminates with “Maximum execution time of X seconds exceeded.” WordPress and plugins can call set_time_limit() to ask for more seconds, but hosts often disable that function, cap the ceiling, or still kill the worker at the proxy layer. This is a duration fatal, not memory exhaustion or a parse error: the code keeps running until time runs out. On nginx → PHP-FPM stacks, a slow script may also surface as HTTP 504 when FastCGI read timeout fires before PHP prints the fatal. Fixing execution time means shortening the work (queries, loops, remote calls) or aligning PHP, FPM, and proxy timeouts for tasks that legitimately need longer.

Common symptoms

Error log or debug.log shows “Maximum execution time of … seconds exceeded” with a file and line
Heavy admin tasks (imports, backups, reports) die while simple pages still load
wp-admin, admin-ajax, or REST endpoints hang then fail with a fatal or HTTP 504
Scheduled cron or Action Scheduler jobs stall with timeout fatals in logs
Page builder save/publish or WooCommerce export stops mid-run without a clear UI error
Raising max_execution_time temporarily completes the task; lowering it reproduces the failure
Gateway or CDN timeout page appears on the same URL where PHP logs show execution time exceeded

Most likely causes

01 Host max_execution_time too low for backup, migration, or import plugins
02 Slow or unindexed MySQL query blocking PHP until the timer expires
03 Plugin or theme loop processing thousands of rows without batching
04 External HTTP API call with no client timeout hanging the request
05 Overlapping wp-cron or Action Scheduler tasks saturating workers
06 set_time_limit disabled or ignored by host policy after a PHP version change
07 Proxy FastCGI read timeout shorter than the legitimate work PHP is doing

What changed before the problem started

New or updated backup, migration, SEO, or sync plugin added long-running jobs
Large product, media, or user import started
PHP version or MultiPHP INI change that lowered max_execution_time
Traffic or bot spike triggering heavy search, cart, or filter queries
Database growth without indexes making formerly fast pages slow
CDN or host proxy timeout tightened after a panel change

Troubleshooting steps

01
Confirm the fatal is execution time, not memory or syntax
Open the host error log or wp-content/debug.log and find “Maximum execution time” / “exceeded.” Note the file path—it often names the plugin or theme. If the message is memory exhausted, undefined function, or parse error, use the matching playbook instead.
02
Raise max_execution_time modestly at the host
In cPanel MultiPHP INI, Plesk, or the host PHP settings, increase max_execution_time to 120–300 seconds for WordPress sites with legitimate heavy admin tasks (if policy allows). Save, wait a minute, and retest the failing workflow once—not as a permanent crutch.
03
Check whether set_time_limit is disabled
In phpinfo, look for disable_functions containing set_time_limit. If disabled, only php.ini and host panels can raise the ceiling; plugin calls to extend time silently fail. Success signal: phpinfo shows the new max_execution_time and whether set_time_limit is available.
04
Identify the slow plugin or cron job
Reproduce with WP_DEBUG_LOG enabled (display off). Match the fatal path to a backup, import, builder, or sync plugin. Temporarily disable likely offenders via FTP folder rename or the host cron bypass (DISABLE_WP_CRON with real system cron) and retest.
05
Look for slow MySQL during the timeout
While reproducing, open MySQL processlist or the host slow query log. Long-running SELECT/UPDATE on wp_postmeta, wp_options, or custom tables often explain timeouts on otherwise “simple” pages. Success signal: killing or optimizing the query lets the page finish under the original time limit.
06
Align proxy timeouts only after PHP is healthy
If logs show PHP finishing but browsers still get 504, raise nginx fastcgi_read_timeout or the host proxy limit slightly above max_execution_time. Do not stack unlimited PHP time with unlimited proxy waits—fix slow code first.

Confirm the fatal is execution time, not memory or syntax

Open the host error log or wp-content/debug.log and find “Maximum execution time” / “exceeded.” Note the file path—it often names the plugin or theme. If the message is memory exhausted, undefined function, or parse error, use the matching playbook instead.

Raise max_execution_time modestly at the host

In cPanel MultiPHP INI, Plesk, or the host PHP settings, increase max_execution_time to 120–300 seconds for WordPress sites with legitimate heavy admin tasks (if policy allows). Save, wait a minute, and retest the failing workflow once—not as a permanent crutch.

Check whether set_time_limit is disabled

In phpinfo, look for disable_functions containing set_time_limit. If disabled, only php.ini and host panels can raise the ceiling; plugin calls to extend time silently fail. Success signal: phpinfo shows the new max_execution_time and whether set_time_limit is available.

Identify the slow plugin or cron job

Reproduce with WP_DEBUG_LOG enabled (display off). Match the fatal path to a backup, import, builder, or sync plugin. Temporarily disable likely offenders via FTP folder rename or the host cron bypass (DISABLE_WP_CRON with real system cron) and retest.

Look for slow MySQL during the timeout

While reproducing, open MySQL processlist or the host slow query log. Long-running SELECT/UPDATE on wp_postmeta, wp_options, or custom tables often explain timeouts on otherwise “simple” pages. Success signal: killing or optimizing the query lets the page finish under the original time limit.

Align proxy timeouts only after PHP is healthy

If logs show PHP finishing but browsers still get 504, raise nginx fastcgi_read_timeout or the host proxy limit slightly above max_execution_time. Do not stack unlimited PHP time with unlimited proxy waits—fix slow code first.

When to stop troubleshooting

Escalate if timeouts persist after reasonable limits and query fixes, the host forbids raising max_execution_time, checkout or admin stay down during business hours, or logs point to encoded plugins you cannot audit. Bring the exact fatal line, phpinfo max_execution_time, disable_functions list, and the plugin/cron active when the timer fired.

Information to collect before requesting help

01 Exact “Maximum execution time … exceeded” log line with file path
02 Effective max_execution_time and disable_functions from phpinfo
03 Whether failure is front end, wp-admin, admin-ajax, REST, or cron
04 MySQL slow query or processlist snapshot during the hang
05 Recent plugin, import, PHP, or proxy timeout changes
06 WordPress, WooCommerce, and backup/migration plugin versions
07 Hosting provider, plan limits, and any resource-throttle notices

How a professional repairs the problem

We confirm the fatal is execution time (not memory or gateway-only 504), raise limits only enough to recover, then profile the slow plugin, query, or API call. We batch or reschedule heavy jobs, align PHP and proxy timeouts for legitimate work, and leave the site finishing normal requests well inside the budget so the next import does not repeat the fatal.

Frequently asked questions

Is this the same as a 504 Gateway Timeout? +

Related but not identical. PHP max execution time is a script fatal. 504 means a proxy stopped waiting. Slow PHP often causes both—check logs on both layers.

Can I set max_execution_time to zero (unlimited)? +

Hosts usually forbid it on shared plans, and unlimited time masks runaway jobs that hurt neighbors. Raise modestly, fix the slow work, then retest under normal limits.

Why do backup plugins trigger this? +

They zip large file trees and database dumps in one HTTP request. Use chunked backups, off-peak schedules, or CLI modes the vendor documents.

Does set_time_limit in wp-config help? +

Only if the host allows the function and the value is below any hard cap. Many hosts disable it—php.ini and the panel setting are the reliable levers.

Can a database problem cause execution time exceeded? +

Yes. An unindexed query or locked table can block PHP until the timer fires. Optimize or kill the slow query, then reassess whether PHP time needs raising at all.

Will caching fix this? +

Page cache helps repeat views of static pages. It does not fix admin imports, cron, or uncached dynamic URLs that still run full PHP every time.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

You will receive a clear explanation of the likely cause.
We will tell you if the issue falls outside our repair scope.
No additional work will be performed without approval.
A backup should be created whenever access and website condition allow it.

Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form.