Runners & CI minutes

Where builds run

Pipelines run on a managed fleet. There is nothing to provision: a runner claims your run, clones the commit into a container of its own, streams the logs back, and is gone. Nothing is shared between two runs, and nothing survives one.

A workspace can also have dedicated runners - machines that only ever take that workspace's work. They are listed in workspace settings and are owner-only, for a specific reason: a runner is handed the decrypted secrets of every repository in the workspace at every claim, and repository secrets are otherwise visible to nobody but the repository's owner. An admin who could mint a runner token could stand up a process that reads all of them and never appear on any repository's collaborator list.

Dedicated capacity is set up with us. A runner needs credentials beyond its own token, so there is no button that mints one and no rezee runner register - ask us and we will bring the machine up. What is yours from the first day is seeing it and taking it away:

$ rezee runner list
$ rezee runner remove builder-1

Removing revokes the token, and it stays yours deliberately: a runner is handed every repository's secrets at each claim, and revoking that should never be something you wait on us for.

The shared fleet belongs to the installation rather than to any workspace, so it does not appear in this list - a workspace has no business revoking the machines that also build for everybody else.

How minutes are counted

Per job, wall-clock, rounded up to the minute.

Per job because a job is what occupies a runner - two jobs of thirty seconds each take two slots, not one. Rounded up because that is what the pricing implies and what every vendor charges.

The consequence is worth knowing before you hit it: a three-job run that takes a few seconds costs three minutes. Splitting a pipeline into forty small jobs to be tidy costs forty minutes every time it runs. Group work into fewer, longer jobs when the minutes matter.

A job that was never picked up occupied nothing and is not counted. The month is calendar, UTC, and the count is kept as a running total rather than summed from the runs - so it survives its runs being deleted, which is the honest accounting: the minutes were spent whether or not the evidence is still around.

Dedicated runners spend no pool at all. Registering one takes the workspace out of the shared fleet's scope entirely, so every one of its builds runs on its own machines - and those minutes are recorded but never counted against a limit and never refused.

The pools

This month's usage against the pool is in workspace settings, and it is on a plain member gate rather than the owner's: "how many minutes are left" is the answer to "why did my build not run", and making it owner-only would mean the one person whose push was refused is the one person who cannot find out why.

A workspace with dedicated runners has no pool to be inside. It sees its minutes and no ceiling.

At 80%, and at the limit

At 80% of the pool, the people who can do something about it are notified. Once per workspace per month - a workspace that jumps straight past the limit in a single job hears "you are out" rather than "you are nearly out".

Past the limit, a push still creates a run. It is recorded with the status quota_exceeded and no container starts. That is deliberate: silence would look like a broken pipeline or a filter that did not match, and the reason a build did not happen belongs in the same list as the builds that did.

Nothing is billed by surprise. The pool comes back when the month rolls over, or immediately on moving up a tier.

Limits inside a run

• A step gets 30 minutes. Past that it is killed and the job fails with that written in the log.
• Runs check out a single commit. A pipeline that needs ancestry - git describe, a commit count, a merge-base diff - should fetch what it needs in a step.
• The clone credential is read-only and valid for that repository alone. Every build step sees it, and a pipeline that could write with it is a pipeline that could rewrite the branch it was asked to test.