Build “Not Running” Due to Concurrency Limit but No Other Job Is Running

Why is this happening?

If a job is not starting and showing a status of "Not Running" after you triggered a pipeline, it means that you have reached the concurrency limit of your plan.

This is most likely to happen to customers on our Free Plan, as they have access to use at most 30 jobs at a time and run, therefore jobs will queue if that many jobs are already in use.

However, customers on performance plans can also encounter this situation as performance jobs have a limit of 80 jobs at a time.

The delayed start of your job, and the fact it remains in a "Not Running" state before eventually starting, is due to the fact that other jobs are still running when the new job is triggered.


Check for Running SSH Jobs

We found that this situation frequently arises due to running SSH jobs; once you navigate away from a running SSH job it won't appear in the pipeline's view, so one can assume that no jobs are running at the time.

SSH jobs, along with all jobs in a given project are listed in the "legacy jobs view":{vcs}/{org}/{project}/jobs

An SSH job will remain available for an SSH connection for 10 minutes after the job finishes - if SSH has not been accessed, then the job will automatically end after 10 minutes.

After you SSH into the job, the SSH connection will remain open for up to two hours. That's why we advise to always manually cancel SSH jobs after you have finished with them to make sure your build queue is as free as possible.

To do so, please follow the instructions outlined in the Support article "How to see running SSH jobs".


Additional Resources:


Was this article helpful?
2 out of 22 found this helpful



Article is closed for comments.