Maximum execution time after a PHP upgrade

Before you start

Save the complete error line and its timestamp in a private note. Record the action that failed, the current PHP versionA PHP version is a numbered edition of PHP, like 8.3. Each edition is looked after for a limited time, then gets security fixes only, then nothing. and any components updated at the same time. Share only information needed for the investigation.

Public support forums are not suitable places for customer details, access credentials or complete server paths.

Back up both files and the database before making changes. Check that the backupA backup is a separate copy of your website's files and database, so you can bring the site back after a mistake, a hack or a failed update. is usable. Work on a restricted test copy with the same PHP version and relevant settings.

Disable real payments and outgoing customer emails there. Agree who will make the change and who will check the result. These steps are an investigation guide, not a diagnosis of your particular website.

Which timer stopped the task? PHP documents max_execution_timemax_execution_time is the PHP setting that limits how long a script may execute. as an execution limit in seconds. The exact accounting depends on the platform and build.

Web servers can also impose their own timeouts. A PHP log entry is therefore needed to distinguish a PHP execution limit from another interrupted connection. A long wait in the browser alone does not establish the cause.

Ask the host to confirm which limit applies to the affected execution. Do not compare a browser request with a terminal task without checking the environment. Record where the measurement is taken and which action it covers.

This lets the host and developer investigate the same event instead of discussing different timers or tasks.

Five steps to a repair

1. Save the exact error line and timestamp. Record the task, input size and last visible result. For an import or synchronization, ask which records have already been written. Have an administrator pause automatic retries where they would otherwise repeatedly start the same unfinished task.
2. Check the active time limit and relevant server logs. Ask whether PHP reports the error or another component terminates the connection. Record the PHP version actually running this task. A setting for a different execution environment does not resolve this diagnosis.
3. Create a small, repeatable test on the test copy. Compare a limited task with a representative one and record both durations. Investigate where execution stalls or performs disproportionate work. Do not change both the data volume and code in the same comparison.
4. Test a targeted solution. Discuss more efficient processing, smaller batches or a managed background task where appropriate. Support any proposed increase in the time limit with measurement and available capacity. Do not remove the limit as a substitute for investigating the cause.
5. Check completion and restart behavior. Were all expected records processed, with no missing steps or duplicates? Safely resume one interrupted attempt on the test copy. Review fresh logs and retain the final result alongside the task size and measured duration.

A report compared with an import

Imagine a report for a short period succeeds while a larger report stops. Use both periods as a comparison for your developer. Request a check that the larger result is complete even when an error screen no longer appears.

A partial report can look convincing while information is missing. Expected counts therefore belong in the acceptance criteria.

For an import, pay particular attention to what has already been saved. Agree beforehand how completed rows will be identified. Ask how the application recognizes a previously processed item when the task starts again.

Demonstrate that behavior with a small test before repeating the full import. This reduces uncertainty around partial processing without prescribing the technical implementation.

A higher time limit is useful only when the task it allows to finish correctly and the required capacity are understood. Request a concrete upper bound and a check after the change. Retain the original error and measurements too.

If the task stops again later, the administrator can compare changes in data volume, code and environment.

Getting help and checking the repair

Use the help form below if you cannot access the logs or do not know who maintains the affected code. Describe one failed action and the expected result. Ask for a proposal that separates the cause, the change and the acceptance check.

Do not include passwords with your request.

After the repair, repeat the original action on the test copy. Also check a normal visitor journey, an empty result and invalid input where relevant. Review fresh log entries at the new test time.

Keep versions and outcomes in your maintenance notes. Let the responsible administrator decide when the tested change can be applied to the live website.