1 पॉइंट द्वारा GN⁺ 2025-12-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude प्लेटफ़ॉर्म पर कई मॉडल्स की error rate बढ़ी हुई बताई गई है
  • उपयोगकर्ता ईमेल या SMS के जरिए आउटेज और समाधान अलर्ट की सदस्यता ले सकते हैं
  • SMS अलर्ट के लिए दुनिया भर के country code list के माध्यम से अलग-अलग देशों के नंबर रजिस्टर किए जा सकते हैं
  • सदस्य OTP (one-time password) सत्यापन के बाद SMS अपडेट प्राप्त कर सकते हैं
  • यह Anthropic द्वारा संचालित Claude सेवा के आउटेज मॉनिटरिंग सिस्टम को दिखाने वाला एक उदाहरण है

Claude सेवा आउटेज सूचना

  • Claude status page पर कई मॉडल्स में error rate बढ़ी हुई स्थिति की सूचना दी गई है
    • “Elevated errors across many models” वाक्य के रूप में दिखाया गया
    • सटीक कारण या प्रभाव के दायरे के बारे में कोई विवरण नहीं है

अलर्ट सदस्यता का तरीका

  • उपयोगकर्ता ईमेल या टेक्स्ट मैसेज (SMS) के जरिए आउटेज अपडेट अलर्ट प्राप्त कर सकते हैं
    • ईमेल में हर बार घटना अपडेट होने पर सूचना भेजी जाती है
    • SMS तब भेजा जाता है जब Claude घटना बनाता है या उसे resolve करता है
    विज्ञापन

SMS अलर्ट पंजीकरण प्रक्रिया

  • SMS अलर्ट पाने के लिए country code चुनना → मोबाइल नंबर दर्ज करना → OTP सत्यापन प्रक्रिया जरूरी है
    • नंबर सत्यापित करने के लिए OTP (one-time password) दर्ज करना होता है
    • सत्यापन के बाद SMS अपडेट प्राप्त किए जा सकते हैं
विज्ञापन

समर्थित देशों की सूची

  • पेज में दुनिया के अधिकांश देशों के country code list शामिल हैं
    • उदाहरण: अमेरिका(+1), दक्षिण कोरिया(+82), जापान(+81), यूनाइटेड किंगडम(+44), जर्मनी(+49) आदि
    • अलग-अलग देशों के उपयोगकर्ता एक ही प्रक्रिया से SMS अलर्ट प्राप्त कर सकते हैं

सेवा स्थिति मॉनिटरिंग का महत्व

  • Claude status page, Anthropic सेवाओं की real-time आउटेज स्थिति सार्वजनिक करने का माध्यम है
    • उपयोगकर्ताओं को पारदर्शी आउटेज अलर्ट और रिकवरी प्रगति साझा करने की सुविधा देता है
    • डेवलपर्स और एंटरप्राइज़ ग्राहकों के लिए service availability तुरंत समझने की व्यवस्था है

1 टिप्पणियां

 
GN⁺ 2025-12-15
Hacker News की राय
  • समस्या होते ही status page को अपडेट किया गया, यह काफ़ी प्रभावशाली लगा
    Claude Code इस्तेमाल करते समय API error आया, तो status page देखा और वहाँ सचमुच outage दिख रहा था
    मुझे लगता है ऐसी पारदर्शी प्रतिक्रिया हर service की default practice होनी चाहिए

    • जैसे ही user impact शुरू होता है, incident को public करना Google और Anthropic में SRE के रूप में काम करते हुए मेरी आदत जैसा instinct बन गया है
      संयोग से मैं खुद Claude इस्तेमाल कर रहा था, इसलिए outage की गंभीरता तुरंत समझ आ गई
    • मैंने भी समस्या आने के 2 मिनट के भीतर status page देखा, और वह तब तक अपडेट हो चुका था
    • मैं 529 error debug कर रहा था, और इस outage की वजह से कुछ देर तक काफ़ी confusion रहा
    • मेरे साथ भी यही हुआ, और status page देखते ही मैंने तुरंत update subscription पर क्लिक किया
      लगता है Claude users रविवार शाम को भी काफ़ी मेहनत से काम कर रहे हैं
  • मैं इस incident response engineer टीम का एक सदस्य हूँ
    14:43 PT / 22:43 UTC तक हमने समस्या को mitigate कर दिया था. असुविधा के लिए खेद है

    • मैं भी उसी टीम का engineer हूँ, और root cause network routing configuration error था
      duplicate route advertisement की वजह से कुछ inference backends की traffic blackhole में चली गई
      detection में लगभग 75 मिनट लगे, और कुछ mitigation paths उम्मीद के मुताबिक काम नहीं कर पाए
      गलत routes हटा दिए गए हैं और service recover हो गई है
      आगे हम synthetic monitoring और infrastructure change visibility को मज़बूत करेंगे ताकि इसे और जल्दी पकड़ सकें
    • क्या Cloudflare की तरह incident analysis report public करने की कोई योजना है?
      उनकी transparency की वजह से मैं Cloudflare पर और ज़्यादा भरोसा करने लगा हूँ
    • जब मुझे सच में Claude से कुछ पूछना था, उसी समय उसका काम न करना काफ़ी मुश्किल था
    • आशा है आपका weekend अच्छी तरह समाप्त हो
    • एक developer के नज़रिए से बस जिज्ञासा है, इतने बड़े deployment environment में इस तरह की समस्या कैसे होती है, इसके बारे में और जानना चाहूँगा
  • 50 साल बाद की एक steampunk dystopia की कल्पना की
    “LLM hosting रुकते ही दुनिया भर का production ठप हो गया और market collapse हो गया. Sam, क्या तुम सुन रहे हो?”
    यह सोचकर ही हँसी आती है

    • यह मानना कि सब लोग वही तीन centralized inference providers इस्तेमाल करेंगे, उतना ही अवास्तविक है जितना यह मानना कि आज सब कुछ us-east-1 और Cloudflare के पीछे है
    • यह शायद internet या Cloudflare के down होने जैसी ही स्थिति होगी
    • याद आया कि Karpathy ने ऐसे outages को ‘intelligence brownout’ कहा था
      संबंधित वीडियो: YouTube Shorts
    • दिमाग में ऐसा वाक्य आता है जैसे, “symbol manipulation में कुशल एक अकेला coder ही मानवता और अंधेरे के बीच बचा है”
    • शायद कोई यह मज़ाक भी करेगा, “हमने समस्या को vibe coding से बनाया, और अब LLM down है तो उसे vibe से ठीक भी नहीं कर सकते”
  • Claude.ai chat में मुझे यह संदेश मिला

    "You have reached the messages quota for your account. It will reset in 2 hours, or you can upgrade now"
    

    या तो timing कमाल की थी, या फिर monetization team को bonus मिलना चाहिए

    • शायद error handling ठीक से implement नहीं हुई थी
      backend या तो 429/402 error throw नहीं कर रहा था, या gateway ने उसे गलत तरह से handle करके गलत message return किया
    • मैंने भी वही message देखा था और सोचा था कि शायद यह बस timing issue है
  • अगर Opus 4.5 को band कर दिया गया, तो शायद मैं रो पड़ूँगा

    • लोग पहले से ही और API credits माँगते हुए नशे के आदी लोगों जैसे लग रहे थे
    • लगता है सभी लोग pricing से काफ़ी संतुष्ट हैं
  • outage से ठीक पहले Opus ने अजीब तरह से बहुत लंबे जवाब देने शुरू कर दिए थे
    साधारण सवालों पर भी वह पूरा codebase उगल देने जैसा जवाब दे रहा था, और database schema से जुड़े एक आसान सवाल में भी दो बार compression हुआ

  • canivibe.ai — हो सकता है किस service का इस्तेमाल हो रहा है, उसके हिसाब से vibe मिल सके

    • site अच्छी है, लेकिन Discord जैसी chat apps में embed ठीक से काम नहीं करता
    • availability 89% होना थोड़ा मज़ाक जैसा आँकड़ा है
    • “Vibedetector” नाम बिल्कुल फिट बैठता है
  • क्या यह कहीं AWS outage तो नहीं था, यह सोच रहा हूँ

  • status page के हिसाब से अब recover हो चुका लगता है
    मैंने agent को उसी error loop में फँसा देखा था, लेकिन इस बार उसने सही result दिया
    लगता है शायद इस तरह के outages को अपने-आप detect करने वाला कोई rule जोड़ा गया है, और यह काफ़ी प्रेरणादायक प्रतिक्रिया लगी