GitHub outage degrades Actions, Pages, webhooks and code search for 90 minutes

GitHub's status page logged another multi-service degradation on October 30, with Actions, Pages, webhooks and code search all affected for roughly an hour and a half. According to a write-up on dev.to, the incident began at 17:50 UTC when GitHub started investigating degraded performance in Actions and Webhooks. Pages was added to the list ten minutes later, and by 18:06 the company was reporting delayed workflow runs, delayed Pages deployments, delayed webhook delivery, and errors in code search and live updates. The incident was marked resolved at 19:23 UTC.

A string of recent incidents

Commenters on Hacker News, cited in the dev.to post, noted that a nearly identical incident had occurred 11 days earlier, and that GitHub had suffered several Actions outages within the past two weeks. The post also flags a quirk of GitHub's status page: the 30-day uptime bar can stay green during an acknowledged incident, because partial degradation does not count as downtime. One commenter reportedly resorted to building a third-party status tracker just to get an accurate picture of Actions availability.

GitHub does expose a public JSON API for its status data, and the dev.to author suggests wiring a small curl-and-jq shell alias to it, so that engineers check whether GitHub itself is broken before rerunning stuck workflows or rolling back commits.

The mirror setup that fails when you need it

The most common backup pattern, a GitHub Action that runs git push --mirror to another forge on every push, depends on GitHub's own job queue. When Actions goes down, the mirror stops updating at exactly the moment it is needed. The author's rule: a mirror has to be driven by something outside GitHub, either your own machine or a forge that synchronizes on its own schedule.

Options that survive an outage

The post lays out four approaches:

Adding multiple push URLs to a single git remote lets one git push reach GitHub, Codeberg and Tangled at once, with no infrastructure required. The catch is that it only mirrors pushes made from that clone; merges completed through the GitHub web UI will not propagate until someone pulls and pushes again, which makes it workable for solo projects but fragile for teams.

Codeberg runs Forgejo, which supports pull mirrors, but Codeberg.org does not allow them. Its FAQ explains that mirrors pulling from other hosting services caused problems, and recommends manual mirroring with multiple remotes instead. The post advises disabling issues and pull requests on a Codeberg backup so nobody files bugs in the wrong place.

A self-hosted Forgejo instance is the option the author would pick for teams. Created through the New Migration flow with the mirror flag set, it pulls from GitHub on a schedule, including changes made in the web UI, and can then fan out push mirrors to Codeberg, Tangled or GitLab. Two warnings from the Forgejo docs: push mirrors force updates and overwrite the target remote, and LFS over SSH is not implemented, so SSH push mirrors will not carry LFS objects.

Tangled, a forge built on the AT Protocol that underpins Bluesky, hosts repositories on "knots" and runs CI on "spindles." Its October 30 release shipped knot2, a Rust rewrite of the knot server, and moved issues, pull requests, comments, reactions and labels onto the knot as collaborative objects described as chains of Git objects inside the repository, so a backup carries the discussion alongside the commits. The gaps matter for backups, though: private repositories are not available yet, with a co-founder quoted as saying they are weeks away; HTTPS push works but is undocumented; Windows cannot clone files with colons in their names; and self-hosted knot operators must upgrade to v1.20.0.

A CI fallback

A mirror with no CI is a read-only archive. The post suggests porting just enough pipeline to run tests and cut releases by hand, pointing to Forgejo Actions, which uses .forgejo/workflows/ files designed to feel familiar to GitHub Actions users while not being compatible with them, and Woodpecker CI via Codeberg's hosted instance.

Why it matters

GitHub remains the de facto home of collaborative software development, and repeated multi-service degradations translate directly into lost engineering time, delayed deployments and broken integrations. The status page's green uptime bar understating partial outages compounds the problem, because teams may distrust their own tooling before suspecting the platform. The practical lesson from this incident is that a backup dependent on the system it backs up is not a backup, and that cheap, independent mirroring to Codeberg, a self-hosted Forgejo or Tangled can turn the next outage from a lost evening into a minor delay. The timing has also given fresh ammunition to alternatives: the same day as the outage, Tangled published an essay arguing that depending on someone else for your uptime has not played out well, which the dev.to author dryly notes works as an advertisement.