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":
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".
Article is closed for comments.