GitHub's account-review bot suspended the service account Actions runs on

TL;DR

• Today, 2026-05-26, roughly 10:40–12:56 UTC, GitHub Actions runs failed. Per GitHub's incident summary, the cause was an automated account-review system that suspended the service account GitHub Actions uses to authenticate workflow runs and download actions.
• Many devs saw a misleading message: "Sorry. Your account was suspended." Their accounts were fine. The suspended account was GitHub's own.
• Mitigated by restoring the account, marking it exempt from further automated review, and redeploying a service to flush cached account state.
• The durable lesson: an automated trust-and-safety enforcement system with authority over first-party service accounts is a blast-radius hazard. The same automation that suspends abusive users took down a product for every tenant.

What broke

If you queued an Actions run this morning, it failed to start. GitHub's incident summary splits the window: from 10:40 to 12:16 UTC, newly queued runs failed to start outright; from 12:16 to 12:56 UTC, runs that needed to download actions for their workflows kept failing while cached state drained.

The confusing part for users was the error text. People hit "Sorry. Your account was suspended." when workflows tried to fetch releases or actions (The Register, 2026-05-27). That message was wrong about whose account was suspended. Your account was not in trouble. The account that got suspended was the internal service identity that Actions runs under, and the error surfaced its suspended state to anyone whose workflow depended on it.

The blast radius reached past Actions into anything that leans on it: GitHub Pages, Copilot Code Review, the Copilot coding agent, Octoshift, and GitHub Enterprise Importer. When the service account was disabled, a small number of Issues, PRs, comments, and discussions were also marked hidden — collateral from the same enforcement action treating a first-party identity like any other suspended account.

Root cause, and how confident to be about it

Confidence labels matter here, because the secondary coverage and GitHub's fuller incident text don't say the same thing at the same depth.

• Incident window and user-facing message: well sourced. The ~10:40–12:56 UTC window comes from GitHub's incident summary; the "Sorry. Your account was suspended." string is corroborated by reporters who reproduced it (The Register).
• Public framing vs. stated root cause: during the event, GitHub's public status updates leaned on generic language — "authentication issues" affecting the majority of Actions runs — and reported the incident resolved at 13:18 UTC. The more specific attribution (an automated account-review system suspending the Actions service account) appears in GitHub's incident summary on the status history. I have not located a separate, detailed RCA blog post; treat this as status-page-level disclosure, not a deep public writeup.
• The mitigation steps GitHub lists are specific and consistent: restore the account (~12:16 UTC), mark it exempt from further automated review (~12:20 UTC), then redeploy a related service (~12:48 UTC) to flush cached account state, with full recovery confirmed ~12:56 UTC. The cache flush is why the tail end of the window kept failing after the account was technically restored.

I'm not going to invent timeline detail GitHub didn't publish. The shape is clear enough without it.

The lesson: your enforcement automation is an availability dependency

Strip the GitHub-specific parts and the failure mode is general. You build an automated system to detect and suspend abusive or compromised accounts. It runs without a human in the loop because that's the point — abuse moves faster than a review queue. Then it scores a first-party service identity as suspicious and suspends it, and now your own product is down for every customer at once.

This is a safety system's false positive presenting as an availability incident. The control that protects the platform from bad actors became the thing that took the platform offline. And because the service account is an authentication identity that many internal services trust, suspending it didn't degrade one feature — it fanned out to everything downstream, plus a misleading message that pointed users at their own accounts instead of the actual fault.

Two properties made it worse:

• No carve-out for internal/critical identities. The enforcement system had authority over an account it should never have been allowed to touch. The fix GitHub applied — marking the account exempt from further automated review — is the carve-out that should have existed before the incident, not after.
• Cached trust state. Even after restoring the account, downstream services kept honoring the stale "suspended" verdict until a redeploy flushed it. Cached authorization decisions extend a wrong call past the moment you reverse it.

If you run automated account or tenant enforcement

You don't need GitHub's scale to have this exact graph. Anyone with an abuse-suspension pipeline and internal service accounts owns this risk.

• Carve out first-party and critical service accounts from auto-suspension. Maintain an allowlist of identities the enforcement system is structurally forbidden to disable. Make it a hard gate in the code path, not a config someone can forget to set.
• Require human confirmation above a blast-radius threshold. If a suspension would affect more than N tenants, or touches an account flagged as infrastructure, hold it for review. Speed is the argument for full automation; for actions that can take down a product, the speed isn't worth the tail risk.
• Don't cache "suspended" verdicts longer than you can flush them. Know how state propagates to downstream consumers and how to invalidate it fast, so a reversal actually takes effect when you make it.
• Fix the misleading message. A suspended service account telling end users their account is suspended sends people debugging the wrong thing. The error surface should distinguish "you are suspended" from "an upstream identity we depend on is unavailable."

None of this is exotic. It's the same blast-radius thinking you'd apply to a deploy or a feature flag, pointed at the enforcement automation you probably built and then stopped threat-modeling.

(GitHub had a separate, unrelated incident two days later, when a partially-deployed auth change rippled across web, REST, git, and Actions; that's GitHub's other May incident, a different failure with a different lesson.)

Sources

• GitHub Status — incident history for 2026-05-26 (primary: incident window, root cause attribution, mitigation steps): githubstatus.com/history. Note: GitHub's public disclosure for this incident is status-page-level; I did not find a separate detailed RCA.
• The Register, 2026-05-27 (corroborates the user-facing "Sorry. Your account was suspended." message and the public-facing resolution time): "GitHub Actions outage told devs 'your account is suspended'"