When a job is waiting or fails

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

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:

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

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?

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