Documentation · Runners

Limits

How long one job may run, how many of your jobs run at once and how to lower that, and what a job cannot do.

How long one job may run, how many may run at once, and what a job cannot do.

A job may run for six hours, the same limit GitHub's own runners apply. A job still running after that is stopped within a quarter of an hour, and its page says why: We stopped this job because it ran longer than your plan allows, or, if our runner stopped it first, We stopped this job because it ran longer than a single job can run here.

A stopped job is billed like a cancelled one, for the time it ran. A build that needs longer should be split into jobs that each finish inside the limit; needs: and artefacts carry work from one to the next.

Your plan sets how many of your jobs may run at the same time. The figure is on the pricing page, and the CI concurrency limit card on Settings shows yours.

A job over the limit waits, queued, until one of your other jobs finishes. Its page says Waiting — you're already running as many jobs as your plan allows. Nothing is billed while it waits, and nothing has failed.

An owner or an admin can set a lower limit on Settings, on the CI concurrency limit card, to bound what the organisation can spend at once. Leave it empty to use everything the plan allows. It can only lower the plan's figure, never raise it. The card appears once GitHub is connected.

• Nested virtualisation. There is no /dev/kvm inside a job, so an Android emulator or a nested hypervisor will not start. Docker containers do not need it and work normally.

• GPUs. There are none.

• ARM, Windows or macOS. Every runner is Linux on x64. Keep those jobs on GitHub's windows-latest or macos-latest; a workflow can mix ours and GitHub's job by job.

• Logging in to a running job. There is no SSH, or any other way in, while a job runs. The job's log, on its page and in GitHub's Actions tab, is what there is.

Runner labels has the sizes, with the memory and disk each one gets.