PHP stops a request when it exceeds its execution limit, but the underlying delay may be CPU work, a database lock, remote HTTP wait or an oversized batch. Raising the number does not make the task efficient and may exceed an earlier proxy timeout.
Preserve the first fatal and check whether the task partially completed before running it again.
Record the task boundary
Note the page/action, item count, start time, fatal time and last confirmed item. Inspect the PHP fatal for file and line.
Compare:
PHP max_execution_time
proxy/web server timeout
remote API timeout
database lock/query duration
browser-reported durationUse protected logs and redact personal or secret parameters.
Map the timeout hierarchy
Write down the deadline at every hop: CDN, load balancer, web server, PHP-FPM, PHP script, database and remote API. The smallest effective value ends the visible request.
Distinguish wall-clock time from CPU execution because PHP configurations do not count every network wait identically. Test the hosting behaviour instead of assuming the configuration label tells the whole story. A background CLI process has a different hierarchy and still needs an operational deadline.
Determine what the named line does
The fatal may point to a loop, database call, filesystem operation or network request. Read the surrounding component code and call stack.
A timeout inside curl_exec() suggests a remote dependency; one inside a database method may hide a slow query or lock. A loop over posts/images suggests batch size.
Do not patch the named line without understanding its inputs and caller.
Check partial side effects
Imports, emails, updates and search replacements can commit item by item. Count what changed and identify stable record IDs.
Before retrying, ensure the operation is idempotent or resume from a checkpoint. Repeating a bulk email or external API action can create customer-facing duplicates.
Take a fresh database/files backup before repairing partial data.
Trace MySQL and remote waits
Match the request with slow-query, lock-wait and provider logs. Set bounded connection and read timeouts for custom APIs.
An external timeout is an unknown outcome. Query the provider by stable reference before retrying a write.
Avoid holding a MySQL transaction open while waiting on a remote service.
Process bounded batches
Split the job into small units with progress stored after each completed batch.
Batch properties:
explicit item IDs
measured batch duration
checkpoint/resume
error list
safe retryUse WordPress cron/Action Scheduler for background work where appropriate, but monitor the queue. A hidden backlog is not a completed task.
Prefer CLI for maintenance
WP-CLI avoids browser and reverse-proxy deadlines and is suitable for imports, replacements and regeneration. It still needs explicit memory/time limits, logging and a rollback.
Run as the correct hosting user, against the intended document root and database. Confirm environment before a destructive command.
Do not assume closing the terminal stops a detached server process.
Change timeouts with evidence
If the measured task is finite, efficient and cannot be batched further, adjust PHP or server limits through supported hosting controls for the maintenance window.
Keep public web requests bounded to protect workers. Restore temporary settings and document them afterward.
Increasing all layers to several minutes can let a single visitor occupy scarce capacity.
Verify workload and site health
Run a small test, then the intended batch while monitoring duration, memory, database and PHP workers. Confirm item counts and that no duplicate side effects occurred.
Test public pages during the operation. Recurring care should identify long-running tasks before updates and schedule them with checkpoints; a reliable WordPress task finishes or resumes deterministically rather than depending on an ever-higher timeout.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
A timeout is a guardrail. The repair is to identify why the request is long, decide whether it belongs in a web request at all and prevent partial work from being repeated blindly.
- Identify the exact action and whether it leaves partial imports, files or database rows.
- Measure database, external API and filesystem time separately.
- Move genuine batch work to WP-CLI, a queue or a scheduled process.
- Raise the timeout only for the controlled operation and document the previous value.
What must be verified
- The operation is idempotent or partial output is handled.
- It completes comfortably inside the limit under realistic load.
- Normal visitor requests remain responsive while it runs.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Should I just raise max_execution_time whenever I see this error?+
Only for a genuine one-off task like a migration script. Raising it on pages regular visitors load is a poor permanent fix — it holds server processes open longer, reduces how many concurrent visitors you can serve, and turns a fast failure into a slow outage instead of solving the actual slowness.
This error shows up during normal browsing, not during an import or update, what does that mean?+
That's a stronger signal of an underlying performance or database problem rather than something to mask with a higher limit. Timeouts during ordinary browsing are worth investigating directly — for example checking a slow-query log for an unindexed query on a large table.
My import timed out partway through, is it safe to just retry it?+
Not without checking first — half-finished imports and backups need to be cleaned up before retrying, or you risk ending up with duplicate data. Confirm what completed before running the operation again.
What's the actual long-term fix instead of continually raising the time limit?+
Move genuinely long-running jobs off the web request entirely — run backups, imports, and similar tasks via WP-CLI or a scheduled process rather than through a browser tied to a 30-second timeout. After changing anything, re-run the operation and confirm it finishes comfortably inside the limit, not just barely under it.