GitHub में Issues, Actions और Git ऑपरेशंस से जुड़ी आउटेज

 (githubstatus.com)
1 पॉइंट द्वारा GN⁺ 2026-02-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GitHub की Actions, Issues, Git ऑपरेशंस जैसी प्रमुख सेवाओं में प्रदर्शन में गिरावट और त्रुटियां रिपोर्ट की गईं
  • प्रभाव का दायरा Webhooks, Pull Requests, Packages, Pages, Codespaces आदि तक फैल गया
  • GitHub ने mitigation लागू कर क्रमिक रिकवरी की पुष्टि की, और बाद में सभी सेवाएं सामान्य हो गईं
  • आउटेज का असर Dependabot, Copilot जैसी कुछ सेवाओं पर भी पड़ा, लेकिन अंततः वे सामान्य प्रोसेसिंग स्थिति में लौट आईं
  • GitHub ने कहा कि वह Root Cause Analysis (RCA) बाद में प्रकाशित करेगा, और उपयोगकर्ताओं के धैर्य और सहयोग के लिए धन्यवाद दिया

आउटेज का अवलोकन

  • GitHub ने घोषणा की कि वह Actions, Git Operations, Issues में प्रदर्शन में गिरावट की रिपोर्टों की जांच कर रहा है
    • शुरुआती चरण में धीमे response और विफल requests, तथा देरी से चलने वाले Actions jobs देखे गए
    • आउटेज पहली बार 9 फ़रवरी 2026 को 19:01 UTC पर रिपोर्ट किया गया

प्रभावित सेवाएं

  • प्रभावित components थे Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages, Codespaces
    • बाद में Dependabot और Copilot में भी समस्याएं पुष्टि हुईं
    • प्रत्येक सेवा को “degraded performance(प्रदर्शन में गिरावट)” स्थिति के रूप में दिखाया गया

प्रतिक्रिया और रिकवरी प्रक्रिया

  • GitHub ने बताया कि mitigation लागू करने के बाद उसने रिकवरी के संकेत देखे
    • 19:29 UTC के बाद क्रमिक सुधार शुरू हुआ
    • 19:54 UTC तक कई सेवाएं बहाल हो चुकी थीं, लेकिन कुछ की जांच अभी भी चल रही थी
  • 20:08 UTC पर रिपोर्ट किया गया कि “सभी सेवाएं सामान्य रूप से प्रोसेस हो रही हैं”
    • 20:09 UTC पर स्थिति Resolved में बदल दी गई

अंतिम स्थिति और आगे की कार्रवाई

  • GitHub ने स्पष्ट किया कि सभी सेवाएं सामान्य संचालन स्थिति में लौट आई हैं
    • Actions, Codespaces, Git Operations, Issues, Packages, Pages, Pull Requests, Webhooks सभी सामान्य हो गए
  • Root Cause Analysis तैयार होते ही साझा किया जाएगा
  • उपयोगकर्ताओं के धैर्य और समझ के लिए आभार व्यक्त किया गया

सारांश

  • यह आउटेज GitHub के मुख्य डेवलपमेंट वर्कफ़्लो के बड़े हिस्से को प्रभावित करने वाली घटना थी
  • रिकवरी पूरी होने के बाद RCA जारी किया जाएगा, जिससे भविष्य में ऐसी समस्याओं को रोकने के लिए सुधारों की उम्मीद है
  • उसी दिन एक और आउटेज रिपोर्ट होने से स्थिरता प्रबंधन के महत्व पर जोर पड़ा

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

1 टिप्पणियां

 
GN⁺ 2026-02-10
Hacker News की राय

  • GitHub की लगातार आंशिक आउटेज की वजह से पूरी कंपनी को किसी दूसरे vendor पर ले जाने पर विचार कर रहा हूँ
    पहले जो फीचर्स ठीक चलते थे, वे अब धीमे हो गए हैं, और Actions भी समय पर नहीं चलते
    Copilot अच्छा है, लेकिन आखिरकार अगर git forge ठीक से काम नहीं करता, तो छोड़ना ही पड़ेगा

    • पूरी तरह सहमत। पहले यह शानदार था, लेकिन अब बुनियादी फीचर्स भी अस्थिर हैं
      एक साधारण PR diff खोलने में भी 15 सेकंड से ज़्यादा लग जाते हैं, और UI बार-बार ऐसे अटक जाता है जैसे फ्रीज़ हो गया हो
      यह हैरानी की बात है कि लोग इस तरह की असामान्य performance degradation को सामान्य मानने लगे हैं
    • “Copilot का मज़ा लेता हूँ” वाली बात अब मज़ाक जैसी लगती है
    • विडंबना यह है कि Linus Torvalds ने git को बिना केंद्रीकरण वाली संरचना के लिए डिज़ाइन किया था
      आखिरकार लोकल पर भी CI pipeline चला पाना ही git का मूल है
      मैं GH का इस्तेमाल सिर्फ sync के लिए करता हूँ
    • पहले GitHub अक्सर postmortem प्रकाशित करता था, लेकिन हाल के दिनों में लगभग नहीं करता
      पुराने लेख देखें तो लगता है कि वह SQL DB की scaling limits से टकरा रहा था
      यह OpenAI के Postgres scaling case जैसा है, लेकिन GitHub शायद उतनी अच्छी तरह प्रतिक्रिया नहीं दे पा रहा
    • “reliable product की उम्मीद करना ही बेकार है” कहकर इसे Microsoft की समस्या बताया गया

  • GitHub की बार-बार होने वाली आउटेज ने उल्टा deployment pipeline resilience को परखने का मौका दिया
    ज़्यादातर टीमें GitHub पर पूरी तरह निर्भर हैं, इसलिए आउटेज होते ही deployment रुक जाता है
    इसलिए इस तरह के विकल्प आज़माए गए

    1. महत्वपूर्ण repo को GitLab या Gitea पर mirror करना
    2. build failure रोकने के लिए dependency caching
    3. GitHub Actions के बिना manual deployment कर सकने वाला runbook तैयार करना
      आधिकारिक status page हमेशा देर से अपडेट होता है, इसलिए अब उसे सिर्फ “eventually consistent” जानकारी माना जाता है

  • हो सकता है GitHub पर automated development workflows के विस्फोट का लोड पड़ रहा हो
    व्यक्तिगत repo में commits विस्फोटक रूप से बढ़े हैं, लेकिन paid conversion लगभग नहीं हुआ

    • समस्या Microsoft अधिग्रहण के बाद से ही शुरू हो गई थी
      2019 में private repo को free करने से monetization का मौका खो दिया गया, ऐसा माना गया
    • असल में समस्या AWS से Azure migration के दौरान है, इसलिए आउटेज बार-बार हो रही हैं
      और downtime को लेकर जवाबदेही की भावना भी कम है
    • आखिरकार यह scaling limits से टकराने की स्थिति है
    • AI code generation की वजह से repo, commit और dataset विस्फोटक रूप से बढ़ रहे हैं
    • इसे “AI Agent boom में जीना, AI Agent crash में मरना” कहकर संक्षेप में बताया गया

  • कुछ लोग GitLab को विकल्प बताते हैं
    GitHub अब सिर्फ AI-केंद्रित रणनीति पर ध्यान दे रहा है, और प्लेटफ़ॉर्म खुद पीछे छूट गया है
    Copilot adoption भी कम है, और कंपनियाँ Claude का ज़्यादा इस्तेमाल कर रही हैं
    अगर Microsoft दिशा बदलता है, तो हालात और बिगड़ सकते हैं

    • यह सवाल भी उठा कि क्या Copilot का अपना मॉडल है
    • लेकिन GitLab भी परफेक्ट नहीं है
      फीचर्स आधे-अधूरे हाल में रिलीज़ होते हैं, और गति भी धीमी है
      open-core model के फायदे भी अब धुंधले लगते हैं
    • GitLab भी AI-केंद्रित होता जा रहा है
      Dev → DevOps → DevSecOps → AI DevSecOps तक विकसित हुआ है, लेकिन
      हर चरण में परिपक्वता कम रही, और license upgrade लगभग अनिवार्य लगता है, जो असुविधाजनक है

  • कुछ लोगों का मानना है कि CI/CD और code hosting को एक साथ बाँधने वाली संरचना ही समस्या है
    सब कुछ सही चले तब भी आखिरकार vendor lock-in से बचना मुश्किल है
    पहले सिर्फ remote बदलना काफी होना चाहिए था, लेकिन अब PR, wiki वगैरह से सब उलझ गया है

    • असल में यह गलती नहीं बल्कि जानबूझकर बनाई गई lock-in strategy लगती है
    • open source समाधान forgejo की तरह स्वतंत्र CI system इस्तेमाल करने से कुछ राहत मिल सकती है

  • अब GitHub की आउटेज सिर्फ SaaS समस्या नहीं, बल्कि cloud-level outage जैसी महसूस होती है
    इसलिए कई टीमें self-hosted GitLab/Gitea की ओर जा रही हैं

    • दो startup में GitLab का सफलतापूर्वक इस्तेमाल किया गया
      एक बड़े enterprise ने security कारणों से on-premise GitLab Enterprise इस्तेमाल किया,
      और व्यक्तिगत प्रोजेक्ट Forgejo पर चलाए जा रहे हैं
      Git, issue, board, wiki सब ठीक चलते हैं, और scoped labels मुफ़्त हैं
    • self-hosted Gitea भी ठीक है। बस backup management अच्छा होना चाहिए
    • GitLab full version self-hosting लागत के मुकाबले काफ़ी मूल्यवान है
    • GitLab self-hosting से निश्चित रूप से संतुष्टि मिली है

  • GitHub के multiple outage history को visualize करने वाला एक पेज भी है
    mrshu.github.io/github-statuses पर देखा जा सकता है

    • updog.ai/status/github भी Datadog डेटा पर आधारित है
    • हालांकि लगता है कि उसका अपडेट रुक गया है (आखिरी अपडेट 6 फ़रवरी का है)

  • “GitHub टीम, आराम से करो” जैसा हल्का-फुल्का मज़ाकिया कमेंट भी था

  • कुछ लोग GitHub छोड़ना चाहते हैं, लेकिन उन्हें stable CI और container registry चाहिए
    अगर कोई “बस ठीक से काम करने वाला” समाधान हो, तो उसके लिए पैसे देने को तैयार हैं

    • Forgejo + Firecracker VM आधारित CI देने वाली Lithus.eu की सिफारिश की गई
      यह बड़े workloads के लिए उपयुक्त है, लेकिन शुरुआती लागत अधिक है
    • GitLab CI सरल होने के साथ शक्तिशाली भी है
      registry permission management थोड़ा जटिल है, लेकिन पूरा integration अच्छा है
    • यह भी सवाल उठा कि क्या repo को ही CI की ज़िम्मेदारी लेनी चाहिए
      Unix philosophy की तरह single-purpose tools पर लौटना चाहिए, ऐसा कुछ लोगों का मानना है
    • nix-ci.com की सिफारिश भी की गई
    • CircleCI भी अब तक ठीक से काम करने वाला विकल्प माना गया

  • AI adoption rate और outage frequency के बीच संबंध का ग्राफ़ देखना दिलचस्प होगा

    • बेशक, इसके अलावा भी कई दूसरे कारक काम कर रहे होंगे