Deployment Stuck in Queued: What to Check First

A deployment stuck in queued is one of the least informative failures a platform can hand you. Nothing has crashed. No logs have appeared, because nothing has run. The release simply sits there, and every refresh shows the same word.

The frustrating part is that "queued" covers at least four different situations, and they have nothing to do with each other. Knowing which one you are in takes about thirty seconds, and it decides whether you should wait, retry, or go look at something else entirely.

What "queued" actually means

A queued deployment has been accepted and recorded but has not yet been given a worker. Between those two moments, a handful of things have to be true:

• The platform has to fetch your source, which usually means an API call to your Git provider.
• A build slot has to be free.
• Any prerequisite in the release has to have finished — a migration step, a volume operation, an earlier deployment of the same service.

If any of those is blocked, the record exists and the work does not start. That is the entire mechanism. It is not a mystery, but most dashboards render all four cases as the same word.

The four cases, in the order worth checking

1. Your Git provider is having a bad day

This is the most common cause and the one you can do nothing about. The platform asked for your repository and got a slow answer or an error. If several unrelated services queue at the same time, and none of them share code, the shared dependency is the provider.

Check your provider's status page before anything else. A deploy that is waiting on an upstream API will clear on its own, and retrying only adds another record to the pile — which is why a stuck queue so often turns into five stuck queues.

2. Something ahead of it has not finished

Most platforms serialise deployments per service, and correctly so: two builds writing the same image tag is not a race you want to win. If an earlier deployment of that service is still running — or worse, still believed to be running because a worker died without reporting — the next one waits.

On Dockup, dockup deployments lists the history most recent first, with each entry's status. If the one above your queued release is not in a terminal state, that is your answer, and cancelling or letting it time out is what unblocks the line.

dockup deployments my-project/my-api --json

The --json output includes each deployment's status and duration, which makes "the previous one never finished" obvious in a way a spinner does not.

3. No capacity

Every platform has a finite number of build workers. On a shared tier, a burst of activity across the platform can put you behind other people's builds. This is real, it is usually short, and it is the one case where waiting is genuinely the right move.

What matters here is whether you can see it. A queue position or a wait estimate turns an outage-shaped experience into a normal one. A bare "queued" does not.

4. The deployment was never going to start

The unhappy case: the record was created, and the thing that was supposed to pick it up never did. A worker crashed, a webhook was lost, a token expired between the trigger and the fetch.

The tell is time. Queue waits are measured in seconds to a couple of minutes. A deployment that has been queued for ten minutes with no other release ahead of it is not waiting — it is stuck, and it will stay stuck.

How to tell a wait from a hang

Before you retry, gather three facts:

1. Is anything else deploying? If another release of the same service is running, you are in case 2 and you should leave it alone.
2. How long has it been queued? Under two minutes is normal. Over ten is not.
3. Did other services queue at the same time? If unrelated services all stopped at once, look upstream, not at your code.

Those three answers separate "wait" from "act" almost every time.

Why retrying usually makes it worse

The instinct with a stuck release is to press deploy again. On a serialised pipeline this is counterproductive: you add a second record behind the first, and if the first is genuinely stuck, the second inherits the block. Developers who hit this often end up with a column of queued entries, none of which will run until the head of the line clears.

If you are going to retry, cancel the stuck one first. One queued deployment that fails visibly is far more useful than five that sit.

What we do about it on Dockup

The design decision that matters here is that a deployment is never believed to be running. Each one has a terminal state, and reaching it is what releases the line. A build that dies without reporting still times out and still frees the service.

Two other things help more than they sound like they would:

Stages are named. A Dockup deployment moves through fetching source, building, and the health gate, and each stage records its own duration. When something is slow you can see which thing is slow rather than watching one word. stageTimings is on every deployment record, including through --json.

Nothing is queued behind a release that already failed. If the health check never passes, the deployment ends — it does not sit occupying the service while you wonder. The previous version keeps serving traffic the entire time, which is the other half of why a stuck release is not an outage on Dockup.

# What is the current state, and how long has each stage taken?
dockup status my-project/my-api --json

# Follow the build as it happens rather than waiting for a summary
dockup logs my-project/my-api --build --follow

The general rule

Queueing is not a failure mode. Queueing without a reason attached to it is. Any platform will occasionally make you wait on a Git provider or a build slot; the difference between a five-minute annoyance and a lost afternoon is whether the interface tells you which of the four cases you are in.

When you are evaluating where to run something, that is worth checking on purpose: trigger a deploy, and look at what the platform shows you between accepting it and starting it. If the answer is a single word with no timestamp, you will eventually spend an afternoon on this.

Frequently asked questions

How long should a deployment stay queued? Seconds to a couple of minutes on a healthy platform. Anything past ten minutes with nothing ahead of it should be treated as stuck rather than slow.

Should I retry a queued deployment? Not before cancelling it. On a serialised pipeline a retry queues behind the stuck one and inherits the same block.

Does a stuck deployment take my site down? It should not. On a platform that only switches traffic after a new release passes its health check, the running version keeps serving throughout — a queued or failed deploy is a release that never happened, not an outage.

Why do several services queue at once? Because they share a dependency, and it is almost always the Git provider or the build fleet rather than anything in your code.