GitHub का ऐतिहासिक uptime

 (damrnelson.github.io)
1 पॉइंट द्वारा GN⁺ 2026-04-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 2016 से 2026 तक के GitHub के मासिक uptime को विज़ुअलाइज़ करने वाला पेज
    • सभी डेटा official status page से एकत्र किए गए रिकॉर्ड्स पर आधारित हैं
  • औसत uptime (Average) और विस्तृत outage विवरण (Breakdown) को अलग-अलग देखकर समझने की संरचना
  • पेज के भीतर मूल डेटा स्रोत (View source) तक सीधे पहुँचना संभव
  • दीर्घकालिक service reliability trend को एक नज़र में देखने लायक विज़ुअलाइज़ेशन सामग्री
  • किसी अलग analysis या explanation के बिना डेटा विज़ुअलाइज़ेशन-केंद्रित संरचना

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-04-01
Hacker News की राय

  • मुझे यह जानने की जिज्ञासा थी कि 2018 से पहले का डेटा वास्तव में सटीक है या नहीं
    मुझे याद है कि पहले भी कई बार आउटेज हुए थे
    हो सकता है कि उन्होंने उसी समय से मौजूदा uptime tracking system का उपयोग शुरू किया हो

    • डेटा आधिकारिक status page से लिया गया है
      लेकिन यह पेज ऑब्ज़र्वेबिलिटी की तुलना में marketing/communication के लिए ज़्यादा लगता है

  • व्यक्तिगत रूप से मुझे यह वैकल्पिक status page ज़्यादा बेहतर लगता है
    “The Missing GitHub Status Page” नाम से, यह पिछले 90 दिनों की availability ratio का समेकित दृश्य दिखाता है
    अभी यह 90.84% है, जो कुछ दिन पहले के 90.00% से थोड़ा बेहतर है

    • हाल की स्थिति काफ़ी उथल-पुथल भरी रही है
      फरवरी 2026 में GitHub Actions की उपलब्धता 98% रही, यानी सिर्फ़ एक ‘9’ स्तर
      अनुभव के हिसाब से ऐसा लगता है कि 50 में से 1~2 बार (लगभग 2%) फेल हुआ
    • इस तरह का समेकित आँकड़ा बहुत तर्कसंगत मेट्रिक नहीं लगता
      उदाहरण के लिए, अगर OpenAI डाउन हो जाए और CoPilot काम न करे, तो क्या उसे GitHub downtime माना जाए?
    • असल में दोनों पेज बस एक ही आँकड़ों को अलग तरीके से दिखाते हैं
      लगता है OP ने इसे Microsoft अधिग्रहण के बाद के नतीजों को उभारने के अंदाज़ में पेश किया है
    • “90% का मतलब लगभग 5 हफ्तों का downtime” निकलता है
      मज़ाक की बात है, लेकिन अब GitHub भी शायद इतनी ‘paid vacation’ का हक़दार हो गया है

  • फ़ीचर कब जोड़े गए, यह दिखाए बिना डेटा दिखाना पक्षपाती है
    उदाहरण के लिए GitHub Actions अगस्त 2019 में लॉन्च हुआ था, इसलिए उससे पहले downtime न होना स्वाभाविक है

    • “Breakdown” में “Actions” पर क्लिक करने से उस आइटम को छिपाया जा सकता है
    • डिटेल पेज में अलग-अलग सेवाओं का पैमाना छोटा हो जाता है, लेकिन कुल ट्रेंड वही रहता है
    • इससे भी बुरा यह है कि जिन अवधियों में वह मौजूद ही नहीं था, वहाँ भी “100% uptime” दिखाया जाता है

  • मैंने भी कुछ हफ़्ते पहले Claude से ऐसा ही ग्राफ़ बनवाया था
    मुझे लगा था कि Microsoft अधिग्रहण से पहले और बाद में तेज़ गिरावट दिखेगी, लेकिन असल में बहुत पहले से ही अनियमित outage pattern चला आ रहा था
    अधिग्रहण से पहले ज़्यादा स्थिरता थी — यह कहानी दिलचस्प है, लेकिन तब Actions जैसा प्रोडक्ट था ही नहीं
    जो सेवाएँ थीं (API, Git ops, Pages आदि), उनके मामले में इसे शायद observability improvements से समझाया जा सकता है

    • Actions लॉन्च होने के बाद से operations और availability के लिहाज़ से जैसे दुःस्वप्न जैसी स्थिति शुरू हो गई
      उसके बाद समस्याएँ Issues और PR जैसे पहले से स्थिर इलाक़ों तक फैल गईं
    • व्यक्तिगत रूप से मुझे लगता है कि GitHub Actions को ही गायब हो जाना चाहिए
      Git मूल रूप से एक काम बहुत अच्छे से करने के लिए बना टूल था, और उस पर अनावश्यक फीचर चिपकाते जाना बड़ी गलती थी

  • अगर लोग वजह ढूँढ़ रहे हैं, तो यह The New Stack लेख शायद कुछ समझा सकता है

    • पूरी तरह सहमत हूँ। हमारी टीम में Azure outages और GitHub outages लगभग एक ही समय पर होते हैं
      अब तो यह एक तरह का मीम बन गया है
    • लेकिन 6 साल से ज़्यादा चली आ रही कम availability को सिर्फ़ इसी एक वजह से समझाना मुश्किल है
      उन्हें अलग environment में पर्याप्त testing करनी चाहिए थी, और कम समय में Azure पर migrate कर लेना चाहिए था

  • अभी PR merge फ़ीचर काम नहीं कर रहा
    संबंधित स्थिति GitHub Status Incident page पर देखी जा सकती है

  • मुझे याद है कि पहले unicorn error page बहुत दिखता था
    शायद उस समय status page इतनी बार अपडेट नहीं होता था

    • unicorn शायद सिर्फ़ web page के लिए होने वाली error थी
      Git API जैसी सेवाएँ अलग से भी टूट जाती थीं, और status page पर कुछ देरी से दिखाई देती थीं

  • अब तो GitHub का downtime record मेरे निजी server से भी बदतर लगता है
    जबकि मैं प्रयोग करते-करते उसे अक्सर reboot करता रहता हूँ या services बंद कर देता हूँ

    • फिर भी हम पैसे देते रहते हैं
      लगता है हम मान लेते हैं कि गुणवत्ता घटे तब भी QoS level बना रहेगा
    • मेरा छोटा सा VPS भी GitHub से मापने लायक स्तर पर ज़्यादा स्थिर है

  • मैं GitHub का बचाव करने वालों में नहीं हूँ, लेकिन उस ग्राफ़ में axis विकृत है
    उसमें सिर्फ़ 99.5% से नीचे का हिस्सा बड़ा करके दिखाया गया है, इसलिए वह वास्तविकता से बहुत ज़्यादा ख़राब लगता है

    • लेकिन अगर उसे 0 से शुरू करें, तो अच्छी और बुरी सेवा के बीच का फ़र्क दिखेगा ही नहीं
      enterprise SLA 99.9% है, जबकि ग्राफ़ का निचला हिस्सा उससे 5 गुना ज़्यादा downtime दिखा रहा है
      यानी यह सिर्फ़ बुरा दिख नहीं रहा, असल में बुरा है
    • ग्राफ़ में load फ़ैक्टर शामिल नहीं है
      Microsoft अधिग्रहण से पहले एक personal repository की सीमा 1 थी, इसे भी ध्यान में रखना चाहिए
    • uptime chart को 0 से शुरू करना ज़रूरी नहीं है
      सिर्फ़ 99% रेंज दिखाना तर्कसंगत है
      मुझे लगता है log scale तो और भी ज़्यादा हो जाएगा

  • मैं GitHub Pages से वेबसाइट deploy करता हूँ, इसलिए मैंने static hosting availability अलग से देखी थी
    इस blog analysis के अनुसार GH Pages इस क्षेत्र में काफ़ी अच्छा प्रदर्शन करता है
    हालाँकि उसका श्रेय शायद Fastly CDN को जाना चाहिए