Your Workflow Queue

Your Own Queue

Every workflow run waits in a queue that belongs to your account, in your account's own place and region. Starting a run only adds it to your queue and answers at once with "queued" (action workflows.run). The work is then done in small turns, so nobody waits on a screen for a big job. Nothing about your queue is kept in another account or in a shared place, so a very large job in another account never slows yours, and yours never slows theirs.

Taking Turns

Each workflow takes its turn. In every round your queue takes one waiting run from each workflow, starting with the workflow that went longest ago. A workflow with a huge number of runs gets one place in each round, like any other, so a small workflow started after a huge one still finishes in its normal time.

Runners Work Side by Side

Your queue hands runs to runners, which work inside your own account's object. A quiet account uses one runner. As the queue grows, more runners start, one for about every 50 waiting runs, up to the runners your account has. They work separate runs side by side, and each keeps many outside calls going at once, since waiting on an outside service takes no turn. The steps of one run always stay in order. The moment the queue is empty, the runners stop and cost nothing.

The One Limit

The number of runners is the only limit. Every account has 1 runner included, and the Extra Runners add-on gives it more (the price is set by the provider, not by MountDev Ops). Extra runners only make work finish sooner: every runner draws on your account's one usage pool, so the same work counts the same however many runners do it. There is no limit on how many outside calls you make or how many steps you use. Going past your included usage never slows or stops work: it is only counted. How hard your workflows call an outside service is up to you, and that service's own limits are yours to sort out. When a service answers "too many requests", the step shows that answer on the run, waits the time the service asked for (or 1 minute, then 5, 30, and 2 hours), and tries again.

How Long a Big Job Takes

See about how long a number of steps takes with your runners, and with 10, with action workflows.estimate, for example "About 3 hours with 1 runner | About 20 minutes with 10". It is an estimate from an average step, and a workflow's own page shows it before you turn the workflow on.

When more runs are waiting than your runners can work, the rest wait in your queue. Nothing is dropped, nothing fails because of it, a wait uses none of a step's tries, and waiting time is never billed.

Seeing the Queue

See how many runs wait, how many are in progress, how many runners you have, and when the oldest was due with action workflows.queue (owners, admins, and anyone whose role allows managing workflows). Each run in the run history shows when it was queued, when it started, and when it finished (action workflows.runs).

Turning It On

The queue is turned on for an account by MountDev Ops, not by a person in the account. Until then runs work the way they always have. When it is turned on, runs that were already waiting are taken into the queue, a share at a time, and nothing is lost or run twice.