If an import, backup or update stops with “Maximum execution time exceeded,” PHP ended a request at its execution limit. Check how far the task progressed before retrying: some records or files may already exist.
The steps below distinguish oversized work, a repeatable failing item and a separate server timeout so you can choose a repair that actually finishes the job.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Quick diagnosis
| Pattern | Next test | Interpretation |
|---|---|---|
| Small batch works; large batch stops | Use smaller resumable batches | Amount of work per request matters. |
| Same item fails every time | Inspect that item on staging | A data or code defect may stop progress. |
| Unrelated pages are also slow | Review hosting resource and worker logs | Wider contention may be involved. |
| Browser shows 504 instead of PHP fatal error | Identify proxy and server deadlines | PHP execution time is only one layer. |
Keep the error and the operation together
Record progress: for an import, note the last saved record and any duplicate-handling option; for a backup, note the stage and whether the archive completed. Do not treat a partially written archive as a verified backup.
Save the complete error message, including the file and line number, and note what you were doing. “The backup stops while creating its archive” is more useful than “WordPress is slow.” The file path may identify the plugin that was running when PHP stopped, although it does not prove that this plugin caused every delay.
Try to establish where the operation reached before it failed. An importer may have saved some products already. A backup may have written only part of its archive. Check those results before repeating the job, so another attempt does not create duplicate records or overwrite the only usable backup.
If the failure began after an update, compare the same operation on a staging copy or with the developer’s recommended settings. Reducing an import batch from a large file to a few sample rows is a useful test: a small successful batch suggests that the workflow works, but needs a better way to handle its full size.
What the PHP setting actually controls
The relevant PHP setting is usually max_execution_time. You may find the active value in your hosting panel or under Tools → Site Health → Info → Server. The number in the fatal error is also a clue to the limit reached by that request.
This limit should not be treated as a universal stopwatch for everything your browser waits for. PHP’s accounting varies by operating system and build. Depending on the environment, time spent waiting on database queries or other external operations may be counted differently. The PHP manual explains those distinctions. Your host can confirm how its server is configured.
A web server, PHP-FPM process manager, or proxy may have a separate deadline. Increasing PHP’s limit will not necessarily change that deadline. If the browser instead reports a 504 gateway timeout, follow the request through those other layers too.
Make large jobs easier to finish
- Preserve a usable backup and record the failing stage.
- Run a small representative batch.
- Compare elapsed work and the last completed item.
- Use the plugin’s supported resume or background workflow for the full task.
For an import, look for smaller batches or resumable background processing. For image optimization, process a portion of the library rather than every image in one request. These changes reduce the amount of work that must finish before a single request ends.
Backups need a different review. An archive stored inside the folder being backed up can make later backups much larger if the tool includes its own previous archives. Review the exclusions and the storage destination, and confirm that any retained backup is usable before removing old copies.
If a task is stuck on the same item every time, size may not be the real issue. A malformed import row, repeated retry, or plugin defect can keep the operation from progressing. Record the last successful item and share a small reproducible sample with the developer, without including customer data.
Increase the limit only when the task calls for it
Some legitimate administrative jobs do need more execution time. Where your host supports it, use its PHP configuration panel to make a modest adjustment, then confirm the active value and test the same operation once. There is no single correct number for every WordPress site.
Local php.ini or .user.ini files work only in environments that support them. Their location and refresh behavior depend on the host. Adding conflicting settings in several directories can make it harder to know which configuration is active.
A value of zero can remove PHP’s normal execution limit in applicable environments, but that is a poor default for diagnosing a live site. An operation that is looping or retrying endlessly still needs repairing. Extending its allowed runtime merely gives it more opportunity to consume resources.
When a larger limit does not help
Look at the error time alongside CPU usage, PHP worker activity, and the server logs. A request waiting behind other busy requests has a different problem from a request spending all its time processing an oversized data set. The host may be able to identify a slow query, a process limit, or a worker that has stopped responding.
Memory is another separate limit. An “Allowed memory size exhausted” message belongs to the PHP memory troubleshooting guide. A failed outbound request with cURL error 28 needs a network and destination check rather than assuming PHP’s execution setting caused it.
Once the task finishes, review its actual output: imported row counts, backup integrity, or the installed plugin version. Keep the successful batch settings and the relevant log entry. For configuration details, consult the PHP manuals for execution time limits and runtime configuration.
Confirm the completed output
Review imported counts and duplicates, or verify the backup with the tool’s supported integrity and restore procedure. Record the effective PHP setting and batch size. If a longer limit merely delays the same failure, return to the slow operation and logs instead of raising it again.