A single dead YouTube refresh token took down an automated publishing pipeline

What happened

On 30 September 2026, the OAuth refresh token behind a small studio's YouTube automation stopped working, and every scheduled job that shared the credential failed with the same error. According to a write-up on dev.to by NeuraGrowth, a one-person digital-products studio, the first alert fired at 05:20 from a statistics job, orqestra.kids_stats, raising a YouTubeRefreshExpired exception with the message: "YouTube refresh_token has expired or been revoked. Reconnect YouTube in /settings (Google OAuth invalid_grant)."

Eight hours later, at 14:00, a second job, orqestra.kids_publish, failed with the same exception. The consequence reached the audience: the Kids publish slot zwierzeta-006 did not go out, nothing was sent in its place, and the alert told the operator to check the videos panel and the channel before publishing that edition by hand. The pipeline's fallback for a dead credential was a human with a checklist, not an automatic retry.

Expired and revoked look identical

The message names two possible states, and the log does not record which one applied or why. That ambiguity is inherent in Google's OAuth: invalid_grant is the error returned when a refresh token can no longer be exchanged for an access token, and the code does not distinguish among the causes.

Google's OAuth documentation lists several conditions that end a refresh token's life. A user can revoke the application's access at any time. A token that goes unused for six months expires. If a user account accumulates too many refresh tokens for one client — the documented limit is 50 — the oldest are invalidated. Refresh tokens issued while an app's OAuth consent screen is still in "Testing" publishing status last only seven days. The dev.to post does not identify which of these, if any, was responsible, which is largely the point: an integration usually cannot tell, so it has to handle all of them.

The lesson the studio drew

When a refresh token dies, every job that depends on it fails in the same way. NeuraGrowth's conclusion is to act on the first failed read rather than wait for the publish to break: reconnect the credential before the next slot. In this incident the 05:20 failure came from a read-only statistics job, while the 14:00 failure hit the publish, where a missed edition has a visible cost. Scheduling cheap reads ahead of expensive writes, and alerting hard on the first authentication failure rather than the first publish failure, would have used the eight-hour window the incident already contained.

Why it matters

Refresh tokens are easy to treat as permanent: they are long-lived, they usually keep working for months, and nothing announces their death in advance. This incident is a reminder that invalid_grant is a normal operating state for a Google API integration, not an exotic bug, and that one shared OAuth credential is a single point of failure across every scheduled job that uses it. Developers wiring YouTube or other Google APIs into automated pipelines should handle the error explicitly, route it to a reconnect action instead of a generic failure, monitor read-only jobs as canaries, and keep a manual fallback for the slots the automation misses. For a one-person operation, that runbook is the difference between a missed edition and a quiet night.