Incident with Git Operations, Pull Requests and Actions – Resolved

Original Article ↗ Hacker News Discussion ↗

Frequent GitHub outages affecting core functions like git push, pull requests, Actions, and even authentication are prompting developers to question its reliability and consider alternatives such as GitLab, Forgejo, Gitea, and self-hosted setups. Commenters point to increased AI-driven usage, GitHub’s migration to Azure, and incentives around free tiers as possible causes, while noting that the downtime is still usually too short to justify the cost and complexity of fully migrating away. Many see this pattern as exposing the risks of over-reliance on a single centralized forge for critical workflows and deployments.

Outage impact and scope

  • Users report inability to push, create PRs or issues, failed auth (e.g., via GitHub-based SSO), and missing commits on PRs.
  • Actions and Pages were failing or delayed, with some jobs not triggering or merge queues stuck for hours.
  • Some saw intermittent “Internal Server Error” on git push, JSON parse errors from HTML 500 pages, and brief unreported blips on previous days.

Perceptions of GitHub reliability

  • Many feel outages are now “every few days” rather than rare monthly events.
  • Several say GitHub has become one of the least reliable services in their stack; some are actively migrating critical workloads off it.
  • Others argue outages are still short (tens of minutes) and tolerable, especially given git’s offline nature, though this is strongly disputed.

Speculated causes

  • Common themes: migration from custom bare‑metal MySQL to Azure; increased load from AI/agentic coding; more features and complexity.
  • Some point to internal warnings about latency and complex live data migration; others question whether Azure is truly causal.
  • A few attribute issues, tongue‑in‑cheek or not, to “AI-coded” systems and loss of deep human understanding.

Status page and incident handling

  • Multiple comments say the status site understated duration/impact and marked incidents “resolved” while errors persisted.
  • Some see this as misleading “padding of stats”; others suggest possible honest mistakes but note repeated patterns.

Alternatives and self‑hosting

  • Users report good experiences with self‑hosted Forgejo/Gitea/GitLab, often combined with S3/OCI registries and separate CI systems.
  • Others highlight the operational burden: replicating issues, PRs, actions, pages, and project management is non‑trivial.

Business and architecture considerations

  • Debate over whether to:
    • Migrate off GitHub entirely,
    • Add redundant deploy paths, or
    • Accept occasional outages as cheaper than major changes.
  • Some argue GitOps / CI tightly coupled to GitHub is fragile; others say true multi‑path deploys are rarely justifiable for most businesses.

Ecosystem lock‑in

  • Several note areas where GitHub is effectively required: Homebrew taps, Terraform/OpenTofu registries, certain cloud workflows, free macOS/Windows runners.
  • Suggested compromise: treat GitHub as a read‑only mirror for discoverability while using another primary forge.