Troubleshooting
What to check when a job waits, fails at once or is refused, and where SuperCI says why.
SuperCI tries to say why, where you will see it: a job it cannot run fails on GitHub with a message at the top of its log, and the dashboard shows the same reason beside the job.
A job stays queued
- The label is not SuperCI’s.
runs-onmust be your control plane’s label (superciunless you chose another), alone or with parts. - The repository is not connected. On GitHub, the App must be installed on it; on GitLab, the project must be turned on.
- Every provider is full. The dashboard’s Runners page says what jobs wait for (“Cloudflare runs 10 at once”). Raise the limit or add a provider.
- It waits for a spot machine. With on-demand turned off and no other provider that fits, a job waits until AWS has a spot machine.
A job fails at once
The first line of its log on GitHub says why. Common ones:
- Nothing can run its machine. The label asks for something no provider you added has: macOS (not supported yet), a GPU without AWS or Modal, a size above your limit.
- A part of the label is not understood. The message lists what a label can say.
- A public repository that is not allowed. See Public repositories.
- AWS allows no GPU machines. New accounts start with a GPU quota of zero. The message links to the quota to raise.
A job was interrupted
AWS took its spot machine back. It is run again by itself once its run has finished. See Spot machines.
A job stops after 70 minutes
That is the time limit for one job.
The dashboard asks to review permissions
A newer version needs something the control plane was not given yet (a permission on AWS, on the GitHub App, or a token scope). Control plane → Permissions lists what is needed and why, with one button to allow it.
The control plane is out of date
The dashboard offers Update when its version is newer than the control plane’s, and lists what the update brings. Updating takes a minute; jobs that are running are not touched.