Note
This article covers a narrow version of a broader issue. For a more comprehensive troubleshooting guide that covers all symptoms, all plan tiers, and all known root causes — including hidden SSH jobs, invalid runner resource classes, high parallelism, and runner maxConcurrentTasks limits, please refer to this article:
Jobs Queuing or Stuck in "Not Running" / "Preparing" State
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.
Customers on Scale plans may also encounter this situation. Instead of showing "Not Running", the job will run but may remain in the "Preparing" state for more than 5 minutes. If this occurs for a Scale customer, please submit a ticket to request a review.
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":
https://app.circleci.com/pipelines/{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".
Check that each self-hosted runner resource class is valid
This issue can sometimes happen when you have resource classes defined that do not have executors associated with them, commonly caused by typos in the resource class name, or loss of access to underlying machines.
Any jobs queued against these invalid resource classes will count towards your concurrency limit, and can lead to queueing with seemingly no jobs running.
Additional Resources:
Comments
Article is closed for comments.