GitHub's Actions service had three separate incidents on 1 October 2026, the longest lasting 9 hours 34 minutes. The fault sat inside GitHub's own infrastructure and its upstream Azure dependency, not in anything you control.
Started
02:00 UTC
Duration
Lasted 9h 34m
Source
IsDown
Next time
GitHub is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Actions
What happened?
GitHub logged three incidents against Actions on 1 October, all filed on its own status page. The first was retroactive: GitHub reported that around 02:00 UTC an isolated infrastructure failure caused Actions to lose execution state for a small number of existing workflow runs. Those runs could get stuck, fail deployment approvals, or error out on cancellation, and GitHub said the lost state could not be restored by retrying an approval. Its fix was to have affected users trigger a new run or contact support with links to stuck runs, then use "Re-run all jobs" to preserve the run ID while starting a fresh attempt. That incident was marked resolved at 11:34 UTC, 9 hours 34 minutes after it began, with a root cause analysis promised but not included in the update. The second incident, elevated request latency, ran from 13:37 to 13:57 UTC, 21 minutes, and GitHub's own updates admit they were still investigating the cause when they closed it. The third incident started at 14:47 UTC and ran 3 hours 11 minutes. GitHub traced it first to Ubuntu runner delays, which it said were resolved, then to Windows runner delays, then to a recurrence, before finally attributing it to an upstream Azure dependency throttling Actions requests and returning 429 errors. GitHub said it escalated to the owning team, applied a mitigation, and watched capacity recover before closing the incident at 17:56 UTC. No user reports were filed during this window on our side. All three incidents affected the single Actions component listed for the day.
Learning
UptimeRobot's own probes, which check api-auth and raw-cdn components from EU and North American regions, stayed at 100% uptime across 24 hours, 7 days and 30 days, and that reading is also correct. Those probes test whether GitHub's API and CDN endpoints answer requests, not whether a specific Actions workflow run retains its execution state or whether a runner queue backs up because of 429s from an upstream Azure dependency. This is the shape of an Actions outage: the front door stays open while the job queue or run state behind it breaks, so a green uptime check and a broken pipeline can coexist without contradiction. GitHub's history over 90 days shows 67 incidents with a median duration of 1 hour 22 minutes, and this day's long incident ran well past that median, with two shorter ones closer to it. Watching your own build logs or CI dashboards tells you jobs are failing, but not whether that is your configuration or GitHub's infrastructure, and GitHub's own updates here needed hours of trial and error, through Ubuntu runners, then Windows runners, before naming the Azure dependency. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
