GitLab · CI/CD jobs · Checked October 28, 2026

GitLab: a job dropped as stuck or over its timeout

If a job does not progress for an extended period, GitLab drops it and records a failure reason; the threshold depends on the state of the job (GitLab: job troubleshooting, checked October 28, 2026). The job then fails with the message for that reason, for example:

The job was stuck in pending state with no matching runners available.
Check your runner tags or configuration

The job was running but showed no activity for an extended period.
Check your job script or try again

The running job exceeded the maximum execution time set for the job

Which threshold, which reason

• Pending, with matching runners: dropped after 24 hours, as stuck_pending_with_matching_runners: "The job was stuck in pending state with matching runners available. Check your job configuration or try again".
• Pending, no matching runners: dropped after 1 hour, as stuck_pending_no_matching_runners: "The job was stuck in pending state with no matching runners available. Check your runner tags or configuration".
• Running, no updates: dropped after 30 minutes with no updates, as no_updates_running: "The job was running but showed no activity for an extended period. Check your job script or try again".
• Canceling, no updates: dropped after 30 minutes with no updates, as no_updates_canceling: "The job was canceling but showed no activity for an extended period. Try again".
• Running, over the timeout: dropped after the configured timeout plus 15 minutes, as server_timeout_running: "The running job exceeded the maximum execution time set for the job".
• Canceling, over the timeout: dropped after the configured timeout plus 15 minutes, as server_timeout_canceling: "The canceling job exceeded the maximum execution time set for the job".

The messages are those of the GitLab source (app/presenters/commit_status_presenter.rb, read on October 28, 2026). On older jobs, or on a GitLab older than 19.0, you may see the reasons these replaced: stuck_or_timeout_failure, "There has been a timeout failure or the job got stuck. Check your timeout limits or try again", which GitLab 19.0 and later keep for historical data only, and job_execution_timeout, "The script exceeded the maximum execution time set for the job", deprecated as a retry value in GitLab 19.1 (retry:when). If the job failed at once instead of waiting, it was not dropped for one of these.

Which timeout applies

• The project: in the project, Settings > CI/CD, expand General pipelines, and enter the Timeout in minutes or as a value like 2 hours. It must be 10 minutes or more and less than one month; the default is 60 minutes. Jobs that exceed it are marked as failed (job time limit).
• The runner: a runner can have a maximum job timeout, used when it is shorter than the project timeout: with 30 minutes on the runner and 2 hours on the project, the job times out after 30 minutes. It is set as Maximum job timeout in seconds, at least 600, or as maximum_timeout through PUT /runners/:id. On GitLab.com, the job timeout of GitLab hosted instance runners cannot be overridden: the project timeout applies (maximum job timeout).
• The job: the timeout keyword sets the timeout of one job. It can be longer than the project timeout, but not longer than the timeout of the runner, and it is not supported in default (timeout).
• No output: the project settings page adds that jobs without an output for one hour are dropped regardless of the timeout, and suggests a script that keeps printing progress.

What to do

• No matching runners: compare the tags of the job with those of the runners. A runner must have all the tags of the job; a runner set to run only tagged jobs leaves a job without tags waiting, and a runner without tags that runs untagged jobs leaves a tagged job waiting (how the runner uses tags). GitLab also names protected status among the requirements a runner may not meet: a protected runner runs only jobs on protected branches or protected tags.
• Matching runners, still pending: check the job configuration or try again, as the message says.
• No activity while running: a script that hangs, or a runner that lost its connection (GitLab: retry:when). Make long steps print progress, and check the runner.
• Over the timeout: raise the project Timeout or the timeout of the job, within the maximum of the runner, or make the job shorter.
• Retry only these: retry:when with retry:max (0, 1 or 2) retries a job for the listed failure reasons only.

test:
  script: rspec
  timeout: 2h
  retry:
    max: 2
    when:
      - stuck_pending_no_matching_runners
      - no_updates_running
      - server_timeout_running

GitLab jobs in IntelliJ IDEA

Pipeline Inbox for GitLab CI, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the pipelines of your GitLab projects with their jobs by stage. Next to a failed job it shows the status, how long the job ran and the message GitLab gives for the failure, such as the ones above (GitLab gives none for a script that failed), and it opens the log of a job in a console viewer at the bottom of the IDE. Reading is free; retrying, cancelling and running are Pro (US$1.50 a month, with a 30-day trial).

GITLAB is a trademark of GitLab Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitLab Inc. or JetBrains.

More: GitLab job log refused or empty · GitLab "This job does not have a trace." after 18.0 · GitLab pipeline or job refused (400, 403, 409, 429) · GitLab pipeline failed with no jobs · GitLab job waiting for resource · GitLab "Insufficient permissions to set pipeline variables" · GitLab 404 "Group Not Found" · GitLab "insufficient_scope" · GitLab pipeline plugins for IntelliJ IDEA, compared · 日本語