Why is this happening?
If a job is not starting and showing a status "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 a single container at any one time (1x concurrency), therefore jobs will queue if that container is already in use.
However, customers on plans with a higher concurrency limit can also encounter this situation.
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 pipelines 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 instructions outlined in the Support article "How to see running SSH jobs".