BuildJet GitHub App Not Installed or Missing Repo Access
If BuildJet cannot see a repository, its runners cannot claim that repo's jobs. Two of BuildJet's documented "waiting for runner" causes are exactly this: app not installed, or repo not granted.
BuildJet reaches your workflows through a GitHub App, so its permissions and repository selection are load-bearing. According to BuildJet's docs, "the GitHub App is not installed" and "BuildJet lacks access to the repository" are two distinct documented causes of jobs waiting for a runner. This page separates and fixes both.
Case 1: app not installed at all
If the BuildJet GitHub App was never installed on the owning account or organization, no BuildJet runner can claim jobs from any of its repos. According to BuildJet's docs, installation runs through its onboarding flow, and if you lack admin rights a repository owner must install it.
Case 2: app installed, repo not selected
GitHub Apps can be scoped to specific repositories. If BuildJet is installed but a particular repo is not in its selected set, that repo's jobs wait indefinitely. Open the BuildJet app's configuration in your GitHub settings and confirm the repository is granted access.
The documented reinstall fix
BuildJet's docs recommend, as a reliable reset when permissions seem correct but jobs still will not start, uninstalling the BuildJet GitHub Application and reinstalling it. This refreshes the app's access. After reinstalling, restart the affected workflow run.
A cleaner model to migrate toward
GitHub App permission drift is common to any third-party runner, including a future one. When you migrate off BuildJet, re-verify the new provider's app scope on day one. Managed runners like Latchkey use the same GitHub App model but add self-healing so transient scheduling hiccups retry rather than silently waiting.