A feature flag at GitHub silently unsubscribed Slack and Teams channels for two hours

Two hours where GitHub told you that you were 'no longer authorized'

The GitHub incident page logs it dryly: "Auth issue resulting in API impacts, including some Slack and Teams channel subscriptions." What that meant on the ground was sharper. An engineer described the moment in the thread:

"a coworker sent a message saying they got a message: their repository messages couldn't be sent, because the user is no longer authorized. The coworker was worried that they might be fired." — a C++ engineer who saw it hit his team

What actually broke, by the timeline

The incident report is specific about cause and blast radius. A recently enabled feature flag caused legitimate authenticated requests to be rejected as unauthorized between 14:49 and 16:45 UTC. The chat integrations interpreted those spurious auth failures as a signal to drop subscriptions — so Slack and Teams channels were silently unsubscribed from their repos. The numbers GitHub published were small in aggregate: a "small but elevated percentage" of authenticated requests failed, driving a 1–2% rise in 4xx errors on specific endpoints, with the vast majority of traffic unaffected.

The resolution sequence:

• 17:20 UTC — GitHub begins investigating impacted performance.
• 18:04 UTC — root cause identified as the feature flag; flag disabled as mitigation; users told they "can manually re-subscribe their repo."
• 18:05 UTC — degradation mitigated.
• 20:34 UTC — impact scope quantified (1–2% 4xx increase, 14:49–16:45 UTC window).
• 22:21 UTC — "Affected Slack and Teams subscriptions have been restored."

So the fix had two halves: kill the flag fast, then — hours later — actually restore the subscriptions it had deleted, instead of leaving every team to rebuild them by hand.

The thread: 'this is an incident now?'

The devops reaction was not sympathy but recognition. Several people said the integration breaks quietly on a regular basis with no status page at all:

"Our github->slack subscription breaks every few months, they never acknowledged it before. At this point we have a doc with the list of repos and settings… we just go through it and resubscribe." — an engineer who keeps a resubscribe runbook

Another reader recognized it only in hindsight:

"I was wondering why my auth expired and I had to resubscribe in one of my channels… I assumed I just missed a reminder email or message." — a commenter who'd silently hit the same bug

The reliability take pointed out this wasn't a one-off:

"So they lasted 9 days until another incident… GitHub's reputation has been long overcooked and you are better off self-hosting and you would have better up time than GitHub." — a commenter citing the prior incident nine days earlier

And a platform engineer made the longer-term case for owning the stack:

"I've been running GitLab internally on k8s for 6 years… Monthly upgrades are painless… I can't see a single area where [GitHub] is better." — a Boston-area platform engineer running self-hosted GitLab

A small flag, a load-bearing default

The technical lesson is narrow but real: an auth failure and an intentional unsubscribe should never share a code path. A transient 4xx from a misfiring feature flag got promoted into a destructive, persistent state change — deleting subscriptions — when the safe default would have been to retry or hold. GitHub did the right thing by restoring the lost subscriptions rather than shrugging and telling everyone to rebuild them, but the fact that a 1–2% error blip could quietly sever integrations for two hours is the part the runbook-keepers in the thread had already learned to expect.