# 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.

![Tasks pile up during a release and workers take them from the front as each one frees up. The queue drains in order until it is empty.](/illos/queue-backlog.svg)

## 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

```bash Terminal
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 s
```

A 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.

```yaml kestrel.yaml
queue:
  per_repo: 1
```

> [!NOTE]
> A run waiting on a [spend limit](/billing#spend-limits) or a [rate limit](/runs/rate-limits) keeps its place in the queue. It starts as soon as the limit allows.