GitLab "Job exceeded the maximum time limit" (Timeout)

By Daniel Zoghalchali·Latchkey

GitLab cancelled the job because it ran past a timeout - set per job, per project, or on the runner. The lowest applicable limit wins.

What this error means

The job is killed mid-run with "execution took longer than Ns seconds" (or the timeout shows in the job header). It is not a script error - the runner stopped the job at the limit.

ERROR: Job failed: execution took longer than 1h0m0s seconds

Common causes

Job genuinely too slow

A large test suite, a slow build, or a hung step outgrew the configured ceiling.

Runner timeout below the job timeout

A runner can cap maximum job time. If its limit is lower than the job or project timeout, the runner value enforces.

A step hangs waiting on input

An interactive prompt or a process waiting on stdin never returns, so the job idles until the timeout fires.

How to fix it

Raise the timeout where appropriate

Set a realistic per-job timeout; the project setting bounds it and a runner cap can override downward.

build:
  timeout: 2h
  script: make release

Speed up or unblock the job

1. Cache dependencies and split long suites with parallel to cut wall time.
2. Make commands non-interactive (-y, CI=true) so nothing waits on stdin.
3. Add per-command timeouts to surface a hung step instead of idling to the limit.

How to prevent it

• Set per-job timeouts that reflect realistic runtimes.
• Keep runner and project timeout ceilings consistent with job needs.
• Cache and parallelize to keep jobs well under the limit.

Frequently asked questions

Related guides

References

• GitHub Actions documentation