Runs
Queue & concurrency
Runs wait in one queue per workspace and start in the order they came in, as workers free up. Nothing is dropped and nothing jumps the line.
How runs start
A new run joins the back of the queue. When a slot is free, the run at the front gets a sandbox and starts. A workspace has as many slots as its plan allows.
| Plan | Concurrent runs |
|---|---|
| Hobby | 1 |
| Team | 20 |
| Enterprise | Set by contract |
Watch the queue
kestrel runs list --status queued
run_9a01 acme/web-app queued position 1 waited 12 s
run_9a02 acme/api queued position 2 waited 9 s
run_9a03 acme/web-app queued position 3 waited 2 sA queued run reports its position, so a dashboard or a CI job can show how long it may wait.
One repo at a time
Two runs on the same repo can open pull requests that clash. Set per_repo to keep a repo to one run at a time; other repos keep starting while it works.
queue:
per_repo: 1Note
A run waiting on a spend limit or a rate limit keeps its place in the queue. It starts as soon as the limit allows.
Was this page helpful?