Tokens. There's More To Them Than AI

By: Michael R. Bagnall

Last Updated: August 1, 2026

Ask anyone outside of our industry about tokens this year and you will get an answer about AI - context windows, prompts, and how much it costs to ask a model a question. Ask a developer who has just watched a pull request go up without a build attached to it, and you will get a very different answer. There is another kind of token quietly running underneath your workflow, and when it goes bad, it does not announce itself.

That token is the OAuth credential Probo.CI holds on your behalf for GitHub, GitLab, or Bitbucket. It is what lets us see your pull request, pull your code, and post a build status back to your repository. Your git hosting provider issues it when you first authorize Probo, and your git hosting provider can invalidate it later - after a password change, an organization policy update, a revoked application authorization, or simply because the provider decided it had lived long enough. None of that involves us, and until recently, none of it told you.

It Looks Like Your Fault. It Is Not.

The frustrating part of an invalidated token is that everything on your side still looks correct. Your .probo.yaml file has not changed. Your subscription is current. Your pull request is open and perfectly ordinary. The build simply never appears, and the natural assumption is that you broke something or that Probo itself is broken.

We have watched teams spend an afternoon on this - rewriting configuration that was already valid, closing and reopening pull requests, checking their billing page twice. The configuration was never the problem.

Three Ways It Shows Up

An invalidated token surfaces in three places, and once you know the pattern it is easy to spot:

• Silence on pull requests. A pull request opens, and no build starts. Nothing appears in Probo, and no status is posted back to GitHub, GitLab, or Bitbucket. No error - just nothing.
• A red box on rebuild. Try to rebuild an existing Probo build and the request comes back with a red error box rather than a running build.
• “Failed to load” on branches. The branch selection menu above your list of builds shows a red “Failed to load” message, because we cannot ask your provider for the branch list.

Any one of those is worth suspecting the token. All three together is close to a diagnosis.

The Sixty-Second Fix

You can clear this yourself right now, and it takes about a minute. Click the Activate Repos button, find your organization, and toggle the affected repository off and then back on again. That round trip forces a fresh OAuth token for your account and organization, and builds start triggering again.

The one catch is permissions: you have to be an administrator on the git repository in question to toggle it. If you are not, this is a job for whoever is, and it is worth telling them exactly what to do rather than filing it as “Probo is broken.”

The full walkthrough, along with the two other reasons builds fail to trigger, lives in Builds Don’t Trigger.

What We Are Doing About It

A one-minute fix is still a fix for a problem you should not have had. The 5.2.0 release adds automatic OAuth token refresh for GitHub, GitLab, and Bitbucket, so tokens renew themselves in the background and stay connected without you re-authorizing anything. For most teams, this class of failure should quietly stop happening. That doesn’t help when the upstream provider revokes the token outright and gives us no chance to refresh it.

That is where the next round of work is aimed, and most of it is GitHub specific. GitHub’s authorization model has the most moving parts of the three providers, between organization approval requirements, application access restrictions, and policies that can pull a token out from under you without warning and a lack of a proper refresh token.

Alongside that, we are building a token access control panel: a single place to see the status of every token Probo holds for your organization, when each one was last refreshed, and a button to refresh one on demand. Invisible credentials are only pleasant when they work. When they do not, you deserve to be able to look at them.

If your builds have gone quiet and the symptoms above look familiar, try the toggle. If they do not, or if the toggle does not help, reach out at hello@probo.ci - we would rather hear about it than have you spend an afternoon rewriting YAML that was fine all along.

Related Articles & Information

---

Builds Don't Trigger Checking & Debugging YAML Configuring the .probo.yaml File