# When a job is waiting or fails (/docs/ci-runners/troubleshooting)



## The job stays queued [#the-job-stays-queued]

Check these in order:

1. **GitHub connection:** the App is connected to the correct BerryBox team and selected repository.
2. **Repository support:** the repository belongs to an organization, is private, and the event is not a fork pull request.
3. **Runner label:** its spelling is exact and the profile is enabled in runner settings.
4. **Credit:** available balance covers the maximum-runtime reservation, including holds for other jobs.
5. **Limits:** the monthly budget, team concurrency and current capacity allow another launch.
6. **Startup:** a cold VM launch or capacity fallback can add a wait. Open the job details for current status.

Do not change every workflow label while investigating. Start with one small compatible job.

## Inspect the failure [#inspect-the-failure]

Open the job in GitHub Actions for full steps and logs. BerryBox shows the job result, timings, provider failure and recorded charge.

With the CLI:

```sh
berrybox jobs --search api
berrybox job --job-id JOB_UUID
berrybox logs --job-id JOB_UUID --search error --limit 50
```

Replace `JOB_UUID` with the BerryBox job ID returned by `jobs`. Log queries search published GitHub output literally; logs may not be available while the job is running. Results are bounded, so use GitHub for the full log.

## Interrupted capacity [#interrupted-capacity]

BerryBox can opt in to retrying eligible Spot-interrupted jobs. Check runner settings before enabling retries: a workflow with deployment or external side effects must be safe to repeat. A retry runs on a new machine and does not resume the process where it stopped.

## Need help? [#need-help]

Email [admin@strawberrylabs.net](mailto:admin@strawberrylabs.net) with the BerryBox job ID and GitHub run URL. Redact secrets and private log content you do not want to share.