GitHub Outage Tracker: Is GitHub Cooked?

Original Article ↗ Hacker News Discussion ↗

A tongue‑in‑cheek “Is GitHub Cooked?” outage tracker sparks broader concern about the reliability of GitHub, especially for enterprises that now see frequent incidents disrupting core workflows like pushes, PRs, and CI via GitHub Actions. Commenters argue over how much sympathy a Microsoft‑owned, highly profitable company deserves, noting that aggressive promotion of AI tools and free tiers has likely amplified load without adequate investment in resilience or traffic segregation between paid and free users. Many see this as a self‑inflicted problem of centralization and product bloat, and some organizations are actively exploring alternatives, even if no replacement yet matches GitHub’s ecosystem.

Reactions to the Outage Tracker

  • Many find the concept funny and apt (jokes about “Outrage Tracker,” xkcd references, etc.).
  • Some note the contribution-graph-as-outage-calendar is a recurring idea.
  • A few commenters inspect the site’s stats and JS, point out initial math/labeling bugs (incidents/month, overlapping incidents, “worst day” > 24h), and note they were quickly corrected.
  • Some caution that the stats are a bit “underbaked” and may not be fully reliable.

Perceived State of GitHub Reliability

  • Widespread sentiment that GitHub’s outage frequency is “abhorrent,” especially for enterprise use.
  • Others report rarely noticing issues, suggesting outages may be time-zone or workload dependent.
  • Several say that in the last months outages feel more frequent and severe, often blocking CI, deployments, and PR workflows.

Causes of Outages and Scale Debate

  • One camp emphasizes unprecedented scale: AI-driven commits, builds, and pushes are described as effectively DDoSing GitHub.
  • Others argue the traffic is large but within what big tech has long known how to handle; they blame technical debt, Azure migration, and management priorities.
  • Some suspect brittle architecture and years of de-prioritized reliability, not just sudden scale.

Paid vs Free Users, Fairness, and Throttling

  • Many paying/enterprise users resent being impacted by traffic from free accounts and AI bots.
  • Proposals:
    • Separate infrastructure or reserved capacity for paying orgs.
    • Stronger rate limits or throttling for automated usage, free tier, or AI-like behavior.
  • Counterpoint: segmenting traffic could clash with GitHub’s open-source/community positioning and AI data-collection incentives.

GitHub Actions, Copilot, and AI Traffic

  • A shared graph suggests removing Actions/Copilot would nearly halve incident counts.
  • Actions is called “critical, not secondary” for many, but also heavily criticized as slow, fragile, and badly designed.
  • Multiple comments say GitHub itself aggressively pushed Copilot and AI workflows, so it “built its own prison” and has limited right to complain about AI-driven load.

Alternatives and Self-Hosting

  • Some organizations seriously discuss moving off GitHub due to repeated outages, but migration cost, compliance, and lock-in are high.
  • Self-hosted GitLab or similar is reported to work reliably for some, with rough cost estimates suggesting big savings versus GitHub enterprise.
  • Others argue most alternatives would also fail at GitHub’s traffic scale and that for small or personal repos, GitHub’s free tier remains the most practical option.

Views on Microsoft and GitHub’s Future

  • Strong anti-Microsoft sentiment from some: claims that acquisitions stagnate products and that GitHub was “cooked” at acquisition.
  • Others distinguish between sympathy for individual engineers/SREs and none for corporate leadership.
  • Several believe that if a credible, simpler competitor appears, many customers are primed to leave, though network effects and feature sprawl may keep GitHub “Excel-like” entrenched.