Job ci-job-hangs-until-timeout · revised 11 October 2026
Stop one CI job from hanging until the timeout cancels it
The named job finishes on its own, within the duration you agreed, on several consecutive runs of the same trigger, without raising its timeout. You receive the cause and the change.
You might be seeing
- The log goes quiet and the job is cancelled after the timeout instead of failing with an error
- Re-running sometimes passes quickly, sometimes hangs, or hangs at the same step every time
No passwords, keys, card details or admin invites needed to start.
What usually happened
A process in the job never exits, so there is no failing command to read. Typical causes are an interactive prompt waiting for input that never comes, a test runner left in watch mode, a server or background process that keeps the step open, a handle that is never closed, or a wait for a service that has already failed. The platform's timeout is the only thing that ends the job, hours later.
Who it’s for: A developer or small team whose job neither passes nor fails: it sits until the platform cancels it, wasting runner time and leaving a pull request without a result.
Usually starts when: The same job ends with a cancelled or timed-out status after a very long run, and the log stops printing output at about the same place.
The result: The named job completes by itself within the duration agreed before work starts on five consecutive runs of the same trigger, its timeout setting is unchanged, and the step that was waiting now ends or fails with a readable message when its condition is not met.
Check whether this job fits
Use your run history, not your code. This check decides whether the job is hanging or merely slow.
Checks you can run yourself
Find where the output stops
Open two cancelled runs of the job and scroll to the last line printed before the cancellation message. Do not re-run the job to answer this.
Look for: The final command or test name, whether it matches in both runs, and the minutes between that line and the cancellation. Remove secrets before sharing.
What you get
- A pull request with the change and a note naming the waiting process and why it never exited
- Run links for the baseline hang and for five consecutive successful runs, with durations
- Steps to revert the change
Included
- One job in one pipeline in one repository
- Find the last step that produced output and the process still running when the timeout fired
- Remove the cause with the smallest change: a non-interactive flag, a bounded wait, a clean shutdown of a background process or a step-level time limit that fails clearly
- Run the job five times in a row on the same trigger and record each duration
Not included
- Raising the timeout to hide the hang
- Jobs that fail quickly with an error: on GitHub Actions that is the existing single-job repair; on GitLab CI it is not covered by a fixed-price outcome, so ask for a quote
- Slow jobs that finish but take too long: that is a performance job
- Application defects that cause a real deadlock in production code
- Self-hosted runner faults that we cannot inspect through an authorised route
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The named job completes without cancellation on five consecutive runs of the same trigger, each at or below the duration agreed before work starts.
Evidence: Five run links in order with the duration of each.
The job's timeout setting is identical to the baseline and no step that previously ran has been skipped, disabled or marked to ignore failure.
Evidence: The independently reviewed diff and a before and after step list.
The step that was waiting now exits normally, or fails with a readable message within a stated bound when its condition is not met.
Evidence: A redacted log excerpt of the step in a passing run and, where the agreement includes it, in a deliberately unmet case on the branch.
Your authorised maintainer accepts the evidence and merges the pull request.
Evidence: Your written sign-off and the merged pull request record.
Sign-off. You inspect the five runs and the diff, sign off in writing and merge the pull request. Payment follows sign-off.
If it fails. If the five runs do not complete as agreed, you do not pay for this fixed scope. If the cause is a live dependency, runner or application deadlock, we hand over the evidence and stop; wider work needs a new written agreement.
When it fits, and when we stop
It fits when
- You can name the job and show at least two recent runs that ended at the timeout
- The job can run on a branch with the same trigger without deploying or using production secrets
- The time at which output stops is visible in the log
- Your maintainer can review and merge the change
We stop and tell you if
- The hang occurs only when a live service the job depends on is unavailable: we report the dependency and stop
- The job only hangs on a runner we cannot reach or on a trigger that deploys
- Repeated attempts show the hang is a real deadlock in application code: we hand over the evidence and stop, because that needs a separate bug-fix scope
What could go wrong
Before merge, closing the pull request leaves your default branch unchanged. After merge, your maintainer can revert the commit and the job returns to its earlier behaviour, including the hang.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| The job passes quickly because the waiting step was removed rather than fixed. | Acceptance requires the step to have executed and exited; the reviewer compares the step list before and after. |
| A repeat run triggers a deploy or publish. | We read every step before any repeat run and stop if one has side effects. |
| Five clean runs hide a rare hang. | We say plainly that five runs are evidence, not proof, and the bounded limit makes a rare repeat fail with a message instead of waiting hours. |
An independent reviewer checks that the five runs executed the real steps rather than skipping them, that the timeout is unchanged and that the added limit fails with a clear message. Your maintainer reviews and merges.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the job, the duration target, the number of repeat runs and the branch-run permission in writing
- Read the hung runs and identify the last output and the process that was still alive
- Reproduce the hang on the agreed branch and record the baseline run
- Remove the cause without raising the timeout or skipping the step, and add a bounded limit so a repeat fails clearly
- Run the job five times in a row on the same trigger and record each duration
- Have an independent reviewer check the runs and the diff, then hand over the pull request and revert notes
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access and necessary permissions are in place. Platform, runner and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
If hangs return as dependencies change, standing CI cover can investigate each one.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Your maintainer can add a step-level time limit to find which step is waiting. GitHub documents step and job time limits, and a job otherwise runs up to six hours by default. docs.github.com
- On GitLab CI, the official job troubleshooting page lists when a job is dropped: a pending job after one hour if no runner matches and after 24 hours if one does, a running job after 30 minutes with no updates, and a running job once its configured timeout plus 15 minutes has passed, each with a recorded reason. The page does not say what counts as an update, so do not assume that a job that has stopped printing output will be ended early. docs.gitlab.com
Questions
Why not just lower the timeout?
A lower timeout makes the hang fail sooner but does not remove it. We find the waiting process, and we add a bounded limit so a repeat fails with a message.
What if the job hangs only sometimes?
That can still be one cause, for example a wait that depends on timing. Five consecutive runs are evidence rather than proof, and we say so in the handover.
Is a job that fails with an exit code covered?
No. On GitHub Actions, a job that fails quickly with an error is the existing single-job repair. On GitLab CI, a job that starts and then fails is not covered by a fixed-price outcome; ask for a quote.
Send an enquiry
Send us
- The job name, trigger and the platform's timeout setting for it
- The last twenty lines of output before the log stops, with secrets and customer details removed
- How long a passing run normally takes, and whether the hang is at the same step each time
- Do not send credentials, source code or an access invitation in the first enquiry
Later, once you agree
- The pipeline file and the commands the job runs, through an authorised company-controlled route
- Read access to the named run logs with the least access needed
- Written approval for repeated branch runs of this job and who reviews and merges
You own the repository, the CI account and the runners. We work from authorised files and redacted logs on a branch through a company-controlled identity. Any repeated run needs your written approval first, and you merge the pull request.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “ci-job-hangs-until-timeout” as the subject.