Fix WordPress Maximum Execution Time Errors Without Hiding Slow Work

A timeout is a boundary doing its job. Imports, image processing, remote APIs, database queries, and accidental loops can all cross it, but they need different fixes.

Start with evidence and the smallest reversible change; work on staging when possible, preserve the logs and rollback material if production is already down, and keep the objective specific: determine whether a request is CPU-bound, waiting on I/O, processing too much data, or trapped in a loop before extending PHP timeouts.

What the symptom narrows down

• A task processes an entire dataset in one web request.
• A remote service or database query consumes most of the time budget.
• Faulty code repeats work without a reliable stop condition.

The branches are ordered to protect the strongest evidence around this possibility: a task processes an entire dataset in one web request. The observed scope and logs—not a familiar-looking error screen—decide which one applies.

Runtime incidents cross several boundaries: the browser reports an HTTP result, the web server hands work to PHP, and WordPress then loads core, plugins, the theme, and data; evidence from the earliest failing boundary is more useful than the component visible on screen; in this guide, the practical goal is to determine whether a request is CPU-bound, waiting on I/O, processing too much data, or trapped in a loop before extending PHP timeouts.

Evidence to collect before the fix

1. Use the fatal log to identify the action and file, then time the same operation on staging.
2. Inspect database slow-query evidence and external request duration.
3. Reduce the input to see whether duration grows linearly or jumps at a particular record.
4. Check PHP, proxy, and host timeouts; the smallest active boundary wins.

The sequence moves from observation toward intervention. Preserve the result of the final check—check PHP, proxy, and host timeouts; the smallest active boundary wins—because it provides a useful comparison after the repair.

Apply fixes in the safest order

1. Split imports and maintenance into resumable batches.
2. Apply explicit, shorter timeouts to external calls and handle failure.
3. Optimize the query or loop before requesting a modest limit increase for legitimate maintenance.

Before applying “Split imports and maintenance into resumable batches,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can run both a small and production-sized test set; a changed symptom at that point is new evidence, not permission to make several more changes at once.

php -r 'echo ini_get("max_execution_time"), PHP_EOL;'
wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence
wp cron event run your_verified_hook --due-now

Prove recovery

• Run both a small and production-sized test set.
• Confirm partial failure can resume without duplicating work.
• Ensure web workers are released promptly when an external dependency fails.

One successful refresh is not closure. Keep the incident open until you can also confirm partial failure can resume without duplicating work, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.

Prepare a useful escalation if the boundary is outside your control

A hosting escalation should include the UTC timestamp, affected URL, response status, request or trace ID when available, PHP version, WordPress version, and the first relevant log entry; redact cookies, passwords, tokens, database credentials, and personal data; include the result of this first observation: use the fatal log to identify the action and file, then time the same operation on staging.

State what was tested, including the result of “Use the fatal log to identify the action and file, then time the same operation on staging,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.

Shortcuts that create a second incident

• Do not use a long browser request for work better handled by a queue or CLI.
• Do not change only PHP when the reverse proxy times out first.

Primary references

• PHP core directives — official reference consulted for this guide.
• WordPress PHP optimization — official reference consulted for this guide.

Editorial note: The scenario above illustrates how to approach “Split imports and maintenance into resumable batches”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.