GitHub pull requests were down

Original Article ↗ Hacker News Discussion ↗

Immediate impact and developer reactions

  • Many commenters were in the middle of workflows involving PRs (including big rebases) and expressed frustration, jokes, or used it as an excuse for an early break.
  • Several noted that a remote outage shouldn’t affect purely local Git operations, but coordination via PRs, webhooks, and issues clearly was disrupted.

Status page and outage scope

  • Some praised GitHub for a relatively transparent status page compared to other providers.
  • Others criticized inconsistencies: the banner mentioned PRs while the detailed components initially showed “Normal” or only referenced webhooks/issues.
  • The page was updated during the incident to explicitly mark PRs and webhooks as in “Incident” state.

Centralization, decentralization, and workflows

  • Multiple comments highlighted that Git is decentralized and still works locally in outages; the single point of failure is GitHub, not Git.
  • Old-school practices (Samba shares, FTP, whiteboards/post-its for file locking, emailing patches) were recalled, partly as jokes, partly as legitimate fallback patterns.
  • Email-based Git workflows (format-patch / send-email / am) and projects like Radicle were cited as more resilient, decentralized alternatives.

AI mandates and irony

  • The outage triggered many references to GitHub leadership’s recent “embrace AI or leave” messaging and Microsoft’s “AI is not optional” stance.
  • Some speculated humorously that AI-driven development or departures of skeptical developers might be backfiring.
  • Broader debate:
    • One side likened AI hype to blockchain and corporate scare tactics.
    • Others argued AI is more like the early web: clearly useful but monetization and best practices are immature.
    • Concerns centered on overconfidence, unreliability, and exec-driven mandates vs organic adoption.

Business impact and SLAs

  • People questioned whether GitHub’s SLAs are acceptable given its central role in software delivery.
  • Counterpoint: organizations choose to centralize on GitHub and must accept outages unless they vote with their feet; network effects make moving hard.

Alternatives and self-hosting

  • Suggestions ranged from secondary remotes (Bitbucket, etc.) to self-hosted GitLab, Gitea, Forgejo, Codeberg, and Radicle.
  • Experiences were mixed:
    • Some praised self-hosting for control and privacy (e.g., avoiding code being used for LLM training).
    • Others found GitLab heavy and burdensome to maintain, yet still liked its CI and container workflows.
    • Forgejo/Codeberg were praised but noted as lacking some GitLab/GitHub features (e.g., convenient scoped registry tokens).

GitHub product direction and performance

  • Several commenters felt GitHub is suffering from feature creep (Projects, Marketplace, Discussions, Codespaces, AI tooling) and neglecting core performance, especially large PR review UIs and search.
  • Others reported no serious performance issues and felt new features don’t interfere with daily work.
  • There was concern that GitHub is shifting focus from being a great Git forge toward being an “AI company.”

Culture, nostalgia, and resilience

  • Some reminisced about earlier eras when long outages meant “snow days” and less anger; now short incidents cause more stress given the pace and centralization.
  • The thread closed with musings on whether future ecosystems will remain centralized like GitHub or fragment into many smaller/self-hosted forges.