Issues और Webhooks में आउटेज – समाधान हो गया

 (githubstatus.com)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GitHub ने Issues और Webhooks में परफॉर्मेंस गिरावट की जांच के बाद 4 मई 2026, 16:40 UTC पर आउटेज की स्थिति को समाधान हो गया में बदल दिया
  • इस आउटेज का असर Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages, और Codespaces पर पड़ा
  • 15:45 UTC पर Issues और Webhooks में परफॉर्मेंस गिरावट की जांच शुरू हुई, और 15:48 UTC पर इसे कई GitHub सेवाओं में latency बढ़ने और timeout की जांच तक विस्तारित किया गया
  • 16:25 UTC से Git Operations, Actions, Packages, Pages, Pull Requests, Issues, Codespaces, और Webhooks क्रमशः सामान्य हुए या उनमें सुधार हुआ
  • GitHub ने कहा कि पूरी सेवा में latency सामान्य हो गई है, और दोबारा ऐसी घटना रोकने तथा root cause analysis पर काम जारी है, जिसे तैयार होते ही साझा किया जाएगा

आउटेज का सारांश

  • GitHub ने Issues और Webhooks में परफॉर्मेंस गिरावट की रिपोर्ट की जांच के बाद घोषणा की कि आउटेज हल हो गया है
  • आउटेज का असर Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages, Codespaces पर पड़ा
  • GitHub ने समस्या के दौरान इंतजार करने वाले उपयोगकर्ताओं का धन्यवाद किया और कहा कि विस्तृत root cause analysis तैयार होते ही साझा किया जाएगा

प्रगति

  • जांच की शुरुआत

    • 4 मई 2026, 15:45 UTC पर घोषणा की गई कि Issues और Webhooks में परफॉर्मेंस गिरावट की रिपोर्ट की जांच की जा रही है
    • 15:48 UTC पर इसे कई GitHub सेवाओं में latency बढ़ने और timeout की जांच तक विस्तारित किए जाने की घोषणा की गई

  • प्रभावित सेवाओं का विस्तार

    • 15:48 UTC पर घोषणा की गई कि Git Operations परफॉर्मेंस गिरावट का सामना कर रहा है
    • 15:50 UTC पर घोषणा की गई कि Packages परफॉर्मेंस गिरावट का सामना कर रहा है
    • 15:51 UTC पर घोषणा की गई कि Actions परफॉर्मेंस गिरावट का सामना कर रहा है
    • 15:51 UTC पर घोषणा की गई कि Pull Requests availability में गिरावट का सामना कर रहा है
    • 15:56 UTC पर घोषणा की गई कि Pull Requests परफॉर्मेंस गिरावट का सामना कर रहा है
    • 16:05 UTC पर घोषणा की गई कि Codespaces परफॉर्मेंस गिरावट का सामना कर रहा है
    • 16:06 UTC पर घोषणा की गई कि Pages परफॉर्मेंस गिरावट का सामना कर रहा है

  • सामान्य स्थिति और सुधार

    • 16:25 UTC पर घोषणा की गई कि Git Operations सामान्य रूप से काम कर रहा है
    • 16:28 UTC पर घोषणा की गई कि Actions और Packages सामान्य रूप से काम कर रहे हैं
    • 16:29 UTC पर घोषणा की गई कि Pages सामान्य रूप से काम कर रहा है
    • 16:29 UTC पर घोषणा की गई कि पूरी सेवा में latency सामान्य हो गई है, और root cause की जांच तथा दोबारा ऐसी घटना रोकने का काम जारी है
    • 16:32 UTC पर घोषणा की गई कि Pull Requests सामान्य रूप से काम कर रहा है
    • 16:34 UTC पर घोषणा की गई कि Issues को प्रभावित करने वाली परफॉर्मेंस गिरावट कम हो गई है और स्थिरता की पुष्टि के लिए निगरानी जारी है
    • 16:35 UTC पर घोषणा की गई कि Codespaces को प्रभावित करने वाली परफॉर्मेंस गिरावट कम हो गई है और स्थिरता की पुष्टि के लिए निगरानी जारी है
    • 16:35 UTC पर घोषणा की गई कि Webhooks सामान्य रूप से काम कर रहा है

  • समाधान

    • 16:36 UTC पर घोषणा की गई कि परफॉर्मेंस गिरावट कम हो गई है और स्थिरता की पुष्टि के लिए निगरानी जारी है
    • 16:40 UTC पर आउटेज की स्थिति को समाधान हो गया में बदल दिया गया
    • विस्तृत root cause analysis उपलब्ध होते ही साझा किया जाएगा

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

1 टिप्पणियां

 
GN⁺ 2 시간 전
Hacker News प्रतिक्रियाएँ

  • GitHub ने agentic coding में बढ़ोतरी को वजह बताते हुए उपयोग में चौंकाने वाली बढ़ोतरी के आंकड़े साझा किए, लेकिन आखिर किसी बिंदु पर उन्हें rate limits बदलनी होंगी, free tier usage घटानी होगी, या लोड कम करने का कोई और तरीका निकालना होगा
    साफ दिखता है कि infrastructure इस बढ़त की रफ्तार के साथ नहीं चल पा रहा, और बढ़ी हुई लागत GitHub हमेशा खुद नहीं उठाएगा। आगे GitHub का क्या होगा, यह देखने लायक है

    • 3 अप्रैल को GitHub COO ने पहले ही कहा था कि platform activity तेज़ी से बढ़ रही है
      2025 में commits 1 billion थे, लेकिन अब यह 275 million प्रति सप्ताह है, इसलिए सिर्फ linear growth मानें तो इस साल 14 billion की रफ्तार बनती है। GitHub Actions भी 2023 में 500 million मिनट प्रति सप्ताह से बढ़कर 2025 में 1 billion मिनट प्रति सप्ताह हो गया, और इस हफ्ते तो यह पहले ही 2.1 billion मिनट तक पहुँच चुका है
      कहा गया कि वे CPU जोड़ने, services scale करने, और GitHub की core functionality को मज़बूत करने के लिए बहुत आक्रामक तरीके से काम कर रहे हैं
      https://x.com/kdaigle/status/2040164759836778878
      availability पर हाल की blog post भी है: https://github.blog/news-insights/company-news/an-update-on-...
      GitHub engineers जिन scalability issues से जूझ रहे हैं, वे सच में आसान नहीं लगते
    • दशकों के अवलोकन में देखा जाए तो कुछ systems हर काम को सस्ता बनाते हैं और कुछ पूरी ताकत से horizontal scaling करते हैं, और अक्सर पहला तरीका दूसरे पर भारी पड़ता है
      उदाहरण के लिए, लगता है GitHub ने repository की /pulls page को search query की तरह implement किया है; prefilled search box इसका संकेत था, और पिछले हफ्ते search backend outage के दौरान pull requests का load न होना इसे लगभग साबित करता है। लेकिन इसे सिर्फ open pull requests लाने वाले साधारण API call से भी बनाया जा सकता था, वह API मौजूद भी है, और उसमें outage नहीं था
      अगर GitHub page loads और उनसे जुड़े API calls जैसे ऊपर के 95% वाले कामों को पहचान कर उन्हें efficient बनाने पर ध्यान दे, तो सिर्फ simplification से ही backend load 5x से ज्यादा कम हो सकता है
      diff viewer में भी सुधार की काफी गुंजाइश लगती है। भयानक inefficiency का बड़ा हिस्सा शायद frontend में हो जो backend को सीधे load नहीं करता, लेकिन साधारण git command line functionality बहुत तेज़ है
    • अब यह point of no return के करीब लगता है। free और paid infrastructure को अलग किए बिना, पता नहीं वे सिर्फ horizontal scaling से अपने ही खोदे गड्ढे से बाहर निकल पाएँगे या नहीं
      जैसे किसी को product बदलवाने के लिए नया product 10x बेहतर होना चाहिए, वैसे ही अगर मौजूदा product 10x बदतर हो जाए तो competitor बिना कुछ किए मुफ्त में 10x फायदा ले लेता है
    • एक हफ्ता पहले GitHub ने blog पर यही बात लिखी, और अगले दिन GitHub executives ने HN comments में उसे दोहराया, तो तुरंत यह आम धारणा बन गई कि 2019 से चल रही reliability गिरावट 2019 की Microsoft integration की वजह से नहीं, बल्कि 2023 में उभरी किसी नई चीज़ की वजह से है
      PR काम करता है। नतीजा यह निकला कि GitHub खराब इसलिए चल रहा है क्योंकि वह बहुत ज़्यादा सफल हो गया है
    • मैं LinkedIn server capacity पूरी की पूरी GitHub को reallocating करने के पक्ष में लंबे समय से हूँ

  • https://mrshu.github.io/github-statuses के मुताबिक पिछले 90 दिनों में GitHub का uptime 84.92% रहा है
    यह थोड़ा भी स्वीकार्य कैसे माना जा सकता है, समझ नहीं आता

    • लगता है वह site downtime को ज़्यादा गिनती है। HN front page तक पहुँचने लायक major और critical outages को ही filter करें तो हालत अभी भी खराब है, लेकिन 84.92% जितनी नहीं
      https://isgithubcooked.com/?severities=major.critical
    • यह स्वीकार्य नहीं है। आजकल बहुत सी अस्वीकार्य चीज़ें हो रही हैं, और फिर भी सब ऐसे पेश आ रहे हैं जैसे कोई बड़ी बात नहीं
    • three nines तो दूर, two eights भी नहीं मिल रहे

  • अब performance अस्वीकार्य स्तर तक पहुँच गई है। शायद ही कोई हफ्ता जाता है जब GitHub की वजह से काम बाधित न हो

    • AI agents ने लगभग पूरे इंटरनेट की scalability characteristics बदल दी हैं
      पहले GitHub यह मान सकता था कि सीमित संख्या में लोग platform को इंसानी तरीके और देखे जा सकने वाले patterns के साथ इस्तेमाल करेंगे, और उसी के हिसाब से scale करेगा और UI/UX bottlenecks optimize करेगा
      लेकिन अब हर किसी के पास 24/7 चलने वाले bots हैं, कभी एक, कभी कई, इसलिए बहुत सी services overload हो रही हैं। खासकर GitHub जैसी services, जो इन दिनों ज़्यादा agent-centric हो गई हैं
    • कुछ महीने पहले से ही यह अस्वीकार्य स्तर पर था, और अब मामला विकल्प सक्रिय रूप से ढूँढ़ने के करीब पहुँच गया है
    • हफ्ते भर नहीं, अब तो outage के बिना सिर्फ एक दिन निकल जाए तो खुशी मनानी चाहिए
      Pacific Standard Time के हिसाब से सोमवार सुबह यह कितनीवीं बार हो रहा है, अब गिनती भी नहीं
    • यूरोप में स्थिति कहीं बेहतर है। यह outage शुरू होने से कुछ घंटे पहले मैं काम खत्म कर चुका था, और पिछले कुछ महीनों में काम रुकवा देने वाले बड़े outages याद नहीं आते
      हाँ, हाल में शाम को hobby project पर काम करते समय एक बार असर पड़ा था
    • मेरा मानना है कि अस्वीकार्य स्तर तो बहुत पहले ही पार हो चुका है

  • अब HN front page पर GitHub down पोस्ट हर हफ्ते नई LLM hype पोस्टों से मुकाबला करती दिखती है
    मैं अपने सभी personal projects को Codeberg पर ले जाने पर विचार कर रहा हूँ। वजह सिर्फ GitHub reliability नहीं, बल्कि यह भी है कि वह big tech company से कसकर बँधा हुआ विकल्प नहीं है

    • Claude Code लगभग जादू है, इस तरह का spam सबसे ज़्यादा था, लेकिन लगता है कुछ समय के लिए वह GitHub status पोस्टों से दब गया है। शायद अभी Claude प्रचार का शांत दौर चल रहा है
    • फिर भी लोग अभी तक migrate नहीं हुए, यही dominant platform की असली ताकत है। थोड़ी असुविधा और inertia ही काफी है ताकि कोई न छोड़े
      monopolistic abuse हो या न हो, यहाँ बात Microsoft की ही है

  • मज़ेदार बात यह है कि Copilot को छोड़कर लगभग सब कुछ degraded performance में दिख रहा है। मज़ाक अपने आप बन रहा है

    • अभी degraded features की तुलना में Copilot की पूरी functionality की उपयोगिता सिर्फ एक छोटा हिस्सा है
    • Copilot शायद GitHub के code hosting हिस्से से पूरी तरह अलग है, और लगता है कि यह ऐसी अलग infrastructure पर चलता होगा जो Rails monolith पर बहुत निर्भर नहीं है

  • अजीब और थोड़ा दुखद है कि GitHub service outage आने का sixth sense विकसित होने लगा है
    करीब एक घंटा पहले pull request में “Resolve Conversation” दबाया तो वह कई बार fail हुआ, और error message page के नीचे, screen से बाहर दिख रहा था इसलिए पहले दिखा ही नहीं। कुछ operations के बाद server की नई state दिखाने के लिए page refresh करना पड़ रहा था
    मैंने एक सहकर्मी से कहा कि लगता है GitHub में किसी दूसरी service में समस्या शुरू हुई है और वह PR comments तक फैल रही है, और शायद यह किसी बड़े outage में बदल सकती है

    • मैंने अभी PR review comments में भी वही संकेत देखा। status page चेक किया तो वह हरा था, लेकिन लगा कि यह ज़्यादा देर नहीं रहेगा, और वही हुआ

  • free tier कम करनी चाहिए
    पिछले 2.5 महीनों में मैंने 4,000 commits किए हैं, वह भी main पर। regression testing artifacts भी रोज़ काफी अपलोड करता हूँ
    इसकी लागत 0 dollars है

    • सच कहूँ तो ऐसे SaaS products की free tier मुझे पसंद नहीं
      पहले जब Google ने बहुत थोड़े समय के लिए GCP पर metered Git service दी थी, मैं वही इस्तेमाल करता था। क्योंकि मैं अपनी चीज़ों का मालिक खुद बनना चाहता था। लेकिन सबने “free” GitHub इस्तेमाल किया, और Google की कई दूसरी services की तरह वह भी बंद हो गई
      इसलिए अभी मैं GitHub मुफ्त में इस्तेमाल कर रहा हूँ, लेकिन मैं repository और usage के लिए किसी बड़े cloud provider को भुगतान करना ज़्यादा पसंद करूँगा
    • ऐसा हुआ तो जो open source projects अभी तक नहीं गए हैं, वे migrate कर जाएँगे
    • repository side को ही देखें तो वह CPU usage के लगभग 2 मिनट के बराबर है
    • GitHub को slopcode tax लगाना चाहिए। Claude के साथ co-authored? पैसे दो। comments में em dash बहुत हैं? पैसे दो। थोड़े समय में बहुत सारा code लिखा गया? पैसे दो

  • यह सच में हास्यास्पद स्तर तक पहुँच रहा है। status page पर कभी-कभी Copilot तक शामिल होने से “गिरा हुआ” कहकर अनदेखा कर दिया जाता है, लेकिन pull request availability 95.5% है, जो Copilot के 96.4% से भी कम है
    जब PR तक access ही नहीं हो पा रहा, तो कोई कैसे उम्मीद करे कि मैं “LGTM” comment डालूँ

  • कम से कम लोग git remote command इस्तेमाल करना तो सीख रहे हैं