GitHub Actions May 26 auth outage: stalled runs, action downloads, and cron

GitHub Actions and GitHub Pages were degraded from 10:57 UTC to 13:18 UTC on May 26, 2026.
In Japan time, that’s 19:57 to 22:18 on the same date.
GitHub Status explicitly tied the issue to authentication problems affecting the start of Actions runs and the download of actions.

This wasn’t just slow runners. Workflow runs could not be started, actions could not be fetched — a failure at the entry layer.
The official status text focuses on run starts and action downloads, but outside reporting also notes that already-running jobs got stuck and that scheduled/cron triggers did not fire.
Some users were confused by “CI checks aren’t running even though I have runner minutes left,” briefly mistaking it for a quota issue.
Retrying CI during that window meant getting blocked at the same authentication layer.

Official Status timeline

GitHub Status lists Actions and Pages as the affected services.
Converted to Japan time, it looks like this.

JST	UTC	State
19:57	10:57	Investigating degraded performance for Actions and Pages
20:19	11:19	Actions experiencing degraded availability
20:53	11:53	Investigating authentication issues leading to failures starting Actions runs and downloading actions; the majority of Actions runs impacted
21:17	12:17	Continued investigation of degraded performance on Actions
21:37	12:37	Cause of the authentication issues affecting Actions identified; mitigation underway
22:00	13:00	Actions and Pages degradation mitigated; monitoring for stability
22:18	13:18	Resolved. Detailed root cause analysis to be shared later

Cyber Security News framed this as a “GitHub Down” event affecting CI/CD pipelines and Pages publishing.
As of May 27, 2026, GitHub has not published a root cause analysis.
The status page only states that an authentication issue affected Actions, that the cause was identified, that it was mitigated, and that it was resolved.

Why Pages got pulled in

GitHub Pages is no longer served only by the older dedicated build infrastructure — it now uses GitHub Actions as the standard deploy path.
GitHub announced this Pages-on-Actions move back in 2022.

So when Actions has trouble starting runs or downloading actions, static-site updates stop too.
That’s why this incident lists both Actions and Pages together.
From the status text alone, you can’t tell whether Pages content delivery was broadly degraded, or whether only the Pages deploy workflow was stuck.

Second time in May, but a different root cause

This was the second Actions outage in May 2026.
On May 15, Actions was degraded from 07:43 UTC to 08:48 UTC, about 65 minutes.
For that one, GitHub did publish a postmortem: a “planned failover of supporting infrastructure used by GitHub Actions, where an automated service discovery update did not propagate correctly.” At peak, around 42% of runs failed or started late, and Pages, Coding Agent, and Code Review Agent were affected as well.

The root cause is different from the May 26 auth incident, but the surface failure mode — Actions stalling at the entry layer — is similar.
Twice in one month, operations that funnel everything through Actions ended up stuck at the same chokepoint.
Watching workflow run statuses with external monitoring would catch this earlier than the Status page updates, as the May 15 postmortem also points out.

Treat release-gating Actions checks as an external service

An Actions outage can block a release even when nothing is wrong with the code or tests.
When the failure mode is “workflow run can’t start” or “action can’t be downloaded,” editing the workflow YAML doesn’t help.

In practice, anywhere production deploy is hard-wired to Actions success is where things get stuck.
A manual deploy bypass, a “hold release” rule, and a “check the status page before retrying” runbook are more realistic to have around.

This is separate from the security angle, but the concentration risk is the same: the more you centralize CI/CD on GitHub Actions, the wider the impact when it goes down.
In GitHub Actions 2026 Security Roadmap I wrote about how to tighten Actions runners, dependencies, secrets, and outbound traffic.
This incident shows no signs of attack or secret leakage, but when Actions stops, tests, deploys, Pages, and security scans all stop together.

What’s still unknown

GitHub said a detailed root cause analysis would be shared later.
As of May 27, 2026, the specific authentication component that broke, why it manifested on both Actions and Pages, and any planned preventive measures have not been published.

So all we can say right now is that an authentication issue propagated to the start of Actions runs and to action downloads, and it took about 2h21m to resolve. Once the RCA lands we can revisit whether this was avoidable in the Actions design.