Short answer: a script exceeded the time PHP allows for a single request (max_execution_time, often 30 seconds) and was terminated. The timeout is a safety mechanism, not the problem. The problem is whatever took that long.
Where it clusters
Timeouts gather around a few operations: plugin and theme updates, imports and exports, backups, bulk edits, image regeneration, and any page that calls a slow external API. If the message appears during ordinary browsing instead, that is a much stronger signal of a performance or database problem worth investigating rather than masking.
Raise it only where it belongs
For a genuine one-off migration you can raise the limit — in wp-config.php with set_time_limit(300); in a maintenance script, or via php.ini/host settings. But raising it on pages real visitors load is a poor permanent answer: it holds server processes open, lowers how many concurrent visitors you can serve, and turns a fast failure into a slow outage.
Find what is slow
- Identify the exact action that triggers it and whether it is reproducible.
- Check whether it completes partially — half-finished imports and backups must be cleaned up before retrying, or you get duplicates.
- Look for slow external calls; a hanging third-party service can stall an otherwise healthy request. Disable that integration temporarily to confirm.
- Review the slow-query log if your host offers one; an unindexed query on a large table is a common cause.
Move long jobs off the web request
The durable fix for genuinely long-running tasks is to run them via WP-CLI or a scheduled process rather than the browser — a full backup or a large import should never depend on a 30-second web timeout. After changing anything, re-run the operation and confirm it finishes well inside the limit, not just under it.
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.