Documentation · Help

Troubleshooting

A job that does not start, a job we stopped, a cache that never hits, an empty sticky disk: what the job page says, and the page that has the fix.

Start at the job's page: open it from Runners in the dashboard. A job that is waiting, or that we stopped, says why at the top, in the words quoted below. If the job is not on the Runners page at all, start at the first question.

We never received the job. Either its runs-on does not start with ghwarp-, so it is not addressed to us, or the GitHub App cannot see that repository. Check the label against runner labels, and the repository against the App's access: Manage on GitHub on the GitHub card on Settings.

GitHub told us the App lost access to the job's repository while the job was waiting: it may have been removed from the App, deleted, renamed or transferred, or the App suspended or uninstalled. Give the App access to it again (Manage on GitHub on the GitHub card on Settings). A job still waiting starts by itself if access comes back within the next few minutes; otherwise it is stopped after several minutes. Nothing ran and nothing was charged, and you re-run it once the App can see the repository.

The label starts with ghwarp- but is not one we sell, or runs-on names something beside our label. The page names the label to change, and runner labels has the rules.

Add a card under Billing on Settings. Add it in the next few minutes and a waiting job starts by itself; if there is still no card about ten minutes on, the job is stopped, and you re-run it. The quickstart has the card step.

The job starts when one of your other jobs finishes. Nothing is billed while it waits. Limits has your plan's figure and the lower limit you can set yourself.

Somebody set a spending cap, and this month has reached it. Raise or remove it on the Usage page, or wait for the month to roll over. Spending alerts and the spending cap has the rest.

A billing hold. Billing on Settings says what is outstanding, or offers Add a payment method. Invoices and payments has the stages of a failed payment.

We place your jobs one at a time while we catch up on your account's status. It clears by itself; if it does not, email us.

A job may run for six hours. Split the work into shorter jobs; see limits.

The job waited about ten minutes on a hold and was stopped. Nothing ran and nothing was charged. What lifts the hold depends on which it was:

• Runs suspended. Either the runners.io GitHub App was suspended from your GitHub organisation's settings, or we suspended the account. Unsuspend the App on GitHub; if you did not suspend it, contact us.

• Your spending cap. Raise or remove it on the Usage page (spending alerts and the cap).

• A disputed charge. Contact us: a dispute is settled with us, not in the dashboard.

• Anything else on billing. Settle what Billing on Settings shows; invoices and payments has the stages.

Then re-run the job.

Nothing ran and nothing was charged. Change runs-on to one of the sizes in runner labels and re-run it.

When other jobs in its workflow run are still going, cancelling one job ends it on GitHub as failed rather than cancelled, because GitHub cannot cancel a single job. Cancelling a job has each case.

The cache is scoped by git ref: a job reads its own ref's entries, then the default branch's, and never a sibling branch's or its pull request's base branch's. A new branch therefore starts from the default branch's entries, or cold if the default branch has saved nothing yet. The Actions cache has the scope and the eviction rules.

The disk was not mounted for that job. The usual reasons: your organisation has not been given sticky disks yet, the build came from a fork or ran a tag, or another job of the same repository held the disk at the time. Sticky disks covers each, and how to guard a step against it.

Email us, with the job's link from its page. The status page says whether something is wrong on our side.