Documentation · Observability
Watching a job
Where a job's logs, timings and states appear, and how to tell a slow build apart from a long wait for a machine.
A job that runs here is still a GitHub Actions job. Its logs stream into the Actions tab on GitHub exactly as they always did, status checks report against the commit, and branch protection sees no difference. Nothing about the pull request experience changes.
The dashboard adds the view GitHub cannot give you: what happened on our side.
Runners in the dashboard lists jobs across every connected repository, grouped by workflow run. Opening one shows the repository, branch, commit, the machine it asked for, who triggered it and the pull request it belongs to — and then the two numbers worth having:
Waited for a runner. How long the job sat before a machine took it.
Ran for. How long it took once one had.
They are shown apart and labelled, because they have completely different causes. A slow build is your workflow; a long wait is us, or a label we do not recognise.
Below that are the job's steps with a duration each, and the log.
| state | means |
|---|---|
queued | accepted from GitHub, waiting for a machine |
assigned | leased to a machine, not yet confirmed running |
running | the runner has claimed the job on GitHub's side |
completed | finished |
failed | an infrastructure failure, not a failing build |
cancelling / cancelled | stopped from the job page, on github.com, or by us refusing the run |
failed is worth reading carefully: it means the machinery failed, not that your tests did. A build whose tests fail reaches completed, and GitHub reports the failure the way it always does.
A job that stays queued is waiting for capacity, or is not addressed to us at all — see runner labels for the second, which is by far the more common of the two and produces no message anywhere. When we know why a job is waiting, the job page says so rather than leaving you to guess.
Cancelling a job covers the button that stops a job, and what GitHub shows afterwards. Test results covers the Tests tab and the optional comment on a pull request.
A job that completes or fails can be sent to a webhook, an email address, Slack or Microsoft Teams. Notifications has the channels, every event, and how to check that a webhook came from us.