GitHub आउटेज को योगदान की तरह दिखाने वाला Red Squares

• Red Squares GitHub के commit contribution graph की पैरोडी है, जो हरे रंग के squares की जगह लाल squares के जरिए GitHub.com प्लेटफ़ॉर्म आउटेज दिखाता है
• हर लाल square उस दिन को दर्शाता है जिस दिन GitHub ने आउटेज झेला, और रंग जितना गहरा हो, उतना लंबा आउटेज रहा
• पिछले 1 साल में GitHub downtime कुल 32.5 दिन दर्ज किया गया
• कम-से-कम 1 incident वाले दिन 167 दिन थे
• सबसे खराब दिन गुरुवार, 30 अप्रैल 2026 था, जब downtime 1.0 दिन तक पहुंच गया

---

GitHub आउटेज को contribution graph के रूप में व्यंग्य

[GN⁺]

Hacker News की राय

• जब भी ऐसी vibe coding meme site सामने आती है, अंतहीन कमेंट आने लगते हैं कि असली वजह लोड नहीं, बल्कि GitHub टीम, tech stack, Microsoft और Azure की खराब हालत है
  public GitHub status page और Enterprise Cloud page की तुलना करें तो Enterprise वाला मेट्रिक्स काफी बेहतर दिखता है, और मुझे भी याद नहीं कि आख़िरी बार कब ऐसा outage हुआ था कि काम ही न हो पाए
  अगर समस्या का लोड से कोई लेना-देना नहीं है, तो Enterprise product में भी वही uptime problem दिखनी चाहिए

  • किसी service को ठीक से न दे पाने की आलोचना करना individual engineer को दोष देना नहीं, बल्कि system failure की आलोचना करना है
    खासकर अगर कंपनी के पास कई देशों से ज़्यादा resources और दुनिया के सबसे बेहतरीन technical talent हों, तो system की आलोचना पूरी तरह जायज़ है
    GitHub का tech stack सच में अच्छा नहीं है, और इसे लंबे समय से काफ़ी अहंकार के साथ defend किया गया है
    Azure एक भयानक platform है, लेकिन टीमों पर इसे जबरन थोपा जा रहा है, और relational database चुनने या frontend rewrite पर भी मैंने रक्षात्मक रवैया देखा है
    जब site को स्थिर भी नहीं रख पा रहे, तब UI दोबारा लिखना और AI tools को धक्का देना समय की बर्बादी है
    यह individual engineers पर हमला नहीं है, बल्कि network effect से लगभग monopoly बन चुके system में core product से ज़्यादा नई features या मालिक की संतुष्टि को प्राथमिकता देने वाले management decisions की आलोचना है
  • यह व्यापक रूप से जाना जाता है कि official status page service-level agreement की वजह से असली downtime को वैसा का वैसा नहीं दिखाता
    status page कंपनी के ख़िलाफ़ सबूत की तरह इस्तेमाल हो सकता है, इसलिए यह तुलना अपने आप में बहुत मायने नहीं रखती
    व्यवहार में outage होने पर भी marketing language में उसे अक्सर “degraded performance” कहा जाता है, और independently run status page काफ़ी ज़्यादा उपयोगी होते हैं
  • लगता है हम अलग-अलग क्षेत्रों में काम करते हैं
    रोज़ नहीं, लेकिन मुझे शायद ही याद हो कि कंपनी में कोई हफ़्ता बिना outage workaround के गुज़रा हो
    ज़्यादातर मामलों में “काम” चलता रहता है, लेकिन outage न होता तो जो चीज़ें उसी समय में build या deploy हो जातीं, वे देर से होती हैं, इसलिए व्यक्तिगत तौर पर मैं कम से कम हफ़्ते में एक बार impact महसूस करता हूँ
  • GitHub कोई छोटी दुकान नहीं है, इसलिए 3 trillion dollar company को यह लोड संभालना चाहिए
    नहीं तो कम से कम ऊपर बड़े अक्षरों में “केवल hobby use के लिए” जैसी warning लगानी चाहिए
  • विडंबना यह है कि इसी वक्त हमारे org में GitHub bug की वजह से PR में नया thread नहीं बनाया जा सकता
    existing thread पर reply कर सकते हैं, लेकिन नया नहीं बना सकते, और यह status page पर भी दिख रहा है
    समझ नहीं आता कि यह कैसे pass हो गया, और यह एक घंटे से क्यों चल रहा है
    ऊपर से fix आने में अभी 3–4 घंटे और लगेंगे, कितनी मेहरबानी है

• external model performance degradation जैसे Gemini 2.5 Pro, Copilot में Grok Code Fast 1, और Claude Opus 4 तक के लिए GitHub को दोष देना मुझे उचित नहीं लगता
  शायद यह ऐसी समस्या है जिसमें GitHub कुछ कर ही नहीं सकता

  • हाल का pattern यह है कि अलग-अलग services की छोटी performance degradation को जोड़कर सबको एक जैसी अहमियत वाले issue की तरह दिखाया जाता है
    severity मिटा दी जाती है और सब कुछ “GitHub outage” या uptime graph में समेट दिया जाता है
    GitHub के हालिया बड़े outages को लेकर नाराज़गी अपनी जगह है, लेकिन छोटी service degradation और पूरे site outage की रेखा धुंधली करके उसे ज़्यादा नाटकीय बनाना, और recommendations, likes, karma, attention बटोरने वाली attention-seeking sites और social posts का बढ़ना अच्छा नहीं लगता
  • hyperscaler की performance degradation को github.com availability से जोड़ना ज़्यादा दिलचस्प नहीं है
    ऐसा लगता है जैसे chart को जितना हो सके उतना लाल बनाना मकसद था
  • अगर GitHub दूसरी services को repack करके दे रहा है, तो GitHub को दोष देना ठीक है
    हम GitHub से कहीं छोटी service चलाते हैं, लेकिन कई providers और कई models के साथ fallback paths तैयार रखे हैं
  • यह इस पर निर्भर करता है कि model को host कौन कर रहा है

• weekend अभी भी एक अनछुआ frontier है
  वहाँ अभी scale करने की गुंजाइश है

  • पिछले महीने जब analysis किया था, GitHub का weekday uptime 89.3% था, जबकि weekend पर 96.5%
    outages weekday के 62% हिस्से और weekend के 11% हिस्से में फैले थे, और Claude भी लगभग ऐसा ही था: weekday 92.5%, weekend 97.8%
    मंगलवार से गुरुवार तक danger zone है, और रविवार तो मानो कोई दूसरी service लगता है
    https://www.aakash.io/tech-chase/github-and-claude-are-down-...
  • तो क्या changes ही सबसे बड़ा कारण हैं?
  • 996 work schedule शुरू होने तक इंतज़ार कर लेते हैं

• पहले तो यही संदेह है कि यह graph सटीक भी है या नहीं
  इसमें लिखा है, “कम से कम एक outage वाले 170 दिन · सबसे बुरा दिन गुरुवार, 20 नवंबर 2025, 1.1 दिन,” लेकिन एक दिन का कुल योग 1.1 दिन कैसे हो सकता है, समझ नहीं आता
  उस तारीख़ पर hover करने पर भी internal calculation method नहीं दिखता, और एक single item 1.3 घंटे दिखता है
  19 नवंबर को 1.3 दिन outage item दिखता है, लेकिन total 8.1 घंटे बताया जाता है

  • missing status page [1] में system का कोई भी component down हो तो उसे downtime माना जाता है, non-overlapping time के आधार पर total uptime निकाला जाता है, और जो समय कम से कम एक individual outage से overlap करता है उसे duplicate counting से बचाने के लिए total downtime में गिना जाता है
    उस तारीख़ पर 24 घंटे का minor outage दिखाया गया है
    यह site शायद एक दिन में सभी services का downtime जोड़ती है, और तब सबसे बुरे दिन में major categories के हिसाब से जोड़कर 10 दिन downtime तक निकल सकता है
    1: https://mrshu.github.io/github-statuses/
  • “1.3 दिन में से 1.0 दिन” वाली item दिखती है, और उससे पहले वाले दिन यानी बुधवार, 19 नवंबर 2025 पर hover करने पर “1.3 दिन में से 7.8 घंटे” दिखता है
    मैंने यह verify नहीं किया कि उस दिन सचमुच downtime था या नहीं, लेकिन अगर मान लें कि नंबर सही हैं, तो 7.8 घंटे में 1 दिन जोड़ने पर लगभग 1.3 दिन बनता है

• official status page [0] और third-party status page [1] के बीच फ़र्क बहुत बड़ा है
  अगर actual product usage से यह इतना अलग है, तो service-level agreement की शर्तें कानूनी कैसे हैं, यह सवाल उठता है
  मुझे GitHub और उसकी service पसंद है, लेकिन जब असल में सब टूटा हो और status page हरा दिखे, तो अंदर से कुछ चीख उठता है
  [0] https://www.githubstatus.com/
  [1] https://mrshu.github.io/github-statuses/

  • शर्तें कानूनी इसलिए हैं क्योंकि service-level agreement के हिसाब से availability track करने और violation होने पर credit claim करने की ज़िम्मेदारी customer की होती है
    हाल ही में जिस जगह काम किया, वहाँ status page पर दर्ज न होने वाले GitHub outages बहुत झेले, और हमने Slack search के ज़रिए उनके logs भी रखे
    बाद में business side के लोगों ने GitHub account rep से बहस की और कुछ सौ डॉलर का credit हासिल किया
    लेकिन उन्होंने शिकायत की कि वह कुछ सौ डॉलर का credit लगाए गए समय के मुकाबले बेकार था, इसलिए GitHub की कम uptime चलती रहती है और कुछ नहीं होता
  • मज़ेदार बात यह है कि कल जब समस्या आई, तो एक सहकर्मी ने mrshu page का link भेजा, लेकिन उस दौरान official page Actions issue दिखा रहा था और वह page पूरा हरा था
  • संभव है कि service-level agreement, GitHub की कुछ functionality को scope में ही न रखता हो
    दूसरी ओर, third-party page किसी एक specific model के outage या problem को भी GitHub issue मानता है, इसलिए actual usage से अंतर आ सकता है

• weekend पर outages बहुत कम होते हैं
  वैसे भी उस समय काम करने का इरादा नहीं होता, तो यह एकदम perfect है

• यह idea पहले से मौजूद था
  जनवरी में मैंने outage category के हिसाब से uptime को तोड़कर देखने के लिए यह बनाया था
  https://isgithubcooked.com

  • “Billing” पूरी तरह हरा है, और “Pull Requests” पूरी तरह लाल

• यह काफ़ी मज़ेदार है कि weekend में लगभग न के बराबर downtime contribution graph जैसा दिखता है