PHP Fatal error: Maximum Execution Time Exceeded in CI
PHP aborts a script that runs longer than max_execution_time. CLI PHP usually defaults to 0 (unlimited), but a runner php.ini, a -d override, or a wrapping process can impose a finite limit, so a long migration, import, or slow test gets killed mid-run.
What this error means
A CLI command or test in CI dies with "Maximum execution time of 30 seconds exceeded" partway through. The same task completes locally where the CLI limit is 0 or higher.
PHP Fatal error: Maximum execution time of 30 seconds exceeded in
/app/src/Importer.php on line 64Common causes
A finite max_execution_time on the runner
The runner php.ini (or a -d max_execution_time=30) sets a finite CLI limit, so a task that legitimately takes longer is aborted.
The work is genuinely too slow
An unbatched import, an N+1 query loop, or a slow external call makes the script exceed any reasonable limit; raising the limit only masks the slowness.
How to fix it
Raise (or unset) the limit for that command
CLI batch jobs typically want 0 (unlimited). Set it per invocation.
php -d max_execution_time=0 bin/console app:import
# or inside the script for a known long task
set_time_limit(0);Set a sane CLI default in the runner config
; php.ini (CLI SAPI)
max_execution_time = 0Make the work faster
- Batch database writes and stream large datasets instead of buffering.
- Eliminate N+1 queries and cache repeated external calls.
- Profile the hot path so the command finishes well within any limit.
How to prevent it
- Set CLI
max_execution_time = 0in the runner image for batch jobs. - Use
set_time_limit(0)explicitly in long-running console commands. - Keep heavy commands batched and profiled so they are not pathologically slow.