ChatGPT، Claude اور Grok ایک ساتھ رکے—مشترک خرابی کا ثبوت نہیں ملا
3 ستمبر 2026 کو ChatGPT، Claude اور Grok تقریباً ایک ہی دورانیے میں دستیابی کے مسائل سے دوچار ہوئے؛ کچھ صارفین کو errors یا سروس تک رسائی میں ناکامی کا سامنا رہا۔ تینوں خدمات بعد میں بحال ہوگئیں، مگر دستیاب سرکاری ریکارڈ اور آزاد رپورٹنگ میں کسی ایک مشترک بنیادی خرابی کی تصدیق نہیں ہوئی۔
اب تک سامنے آنے والی وضاحتیں الگ ہیں: ChatGPT اور Codex کے واقعے کو routing error، Claude کی جزوی بندش کو infrastructure issue اور Grok کے مسئلے کو Memphis compute center کی بندش سے جوڑا گیا۔ اس لیے واقعات کا وقت ایک دوسرے پر چڑھنا اہم مشاہدہ ہے، لیکن بذاتِ خود مشترک cloud یا network failure کا ثبوت نہیں۔
ChatGPT اور Codex میں elevated errors کیسے بڑھے
OpenAI کے سرکاری incident record میں 3 ستمبر کو 14:43 UTC پر ChatGPT اور Codex کے لیے تفتیش شروع ہونے، 15:17 پر mitigation لاگو ہونے اور 16:55 پر مسئلہ حل قرار دیے جانے کا اندراج ہے۔ ریکارڈ میں ChatGPT کے 15 اور Codex کے چار components متاثر دکھائے گئے، جبکہ بعض Codex remote-control صارفین کو واقعے کے بعد اپنا موبائل دوبارہ pair کرنے کی ضرورت پڑ سکتی تھی۔
یہ اوقات status updates کے ہیں، لازماً ہر صارف کے لیے خرابی شروع یا ختم ہونے کے عین لمحات نہیں۔ OpenAI کا dashboard بھی واضح کرتا ہے کہ اس کے availability اعداد تمام tiers، models اور error types کی مجموعی تصویر ہوتے ہیں؛ کسی مخصوص صارف کا تجربہ subscription، model اور استعمال ہونے والی API feature کے لحاظ سے مختلف ہوسکتا ہے۔
بعد میں دی گئی تکنیکی وضاحت کے مطابق routing error تقریباً 07:43 بحرالکاہل وقت پر شروع ہوا اور حل تقریباً 08:17 پر نافذ کیا گیا۔ اس سے ChatGPT اور Codex بعض صارفین کے لیے مختلف platforms پر unavailable ہوئے، لیکن دستیاب بیان نے اسے Claude یا Grok کے واقعے سے نہیں جوڑا۔
Claude کے status log میں دو الگ واقعات ہیں
Claude کے لیے 3 ستمبر کا ریکارڈ ایک مسلسل بندش نہیں بلکہ دو incidents دکھاتا ہے۔ پہلے Claude Sonnet 5 میں elevated errors کی تفتیش 12:37 UTC پر شروع ہوئی، 12:47 پر fix کی نگرانی شروع ہوئی اور 12:56 پر واقعہ حل قرار پایا۔
دوسرا واقعہ 13:26 UTC پر متعدد models کی requests میں elevated errors کے ساتھ شروع ہوا۔ Anthropic کے status log میں Mythos/Fable 5.1، Mythos/Fable 5، Opus 5، Opus 4.8 اور Opus 4.6 متاثرہ models کی مکمل فہرست میں شامل ہیں؛ 15:25 تک صرف Opus 4.8 اور Opus 5 متاثر رہ گئے تھے، اور آخری درج اثر 16:16 UTC پر ختم ہوا۔
بعد کی وضاحت میں اسے infrastructure issue سے پیدا ہونے والی partial outage کہا گیا جس نے Claude.ai، Claude Code، Claude Cowork اور Claude API کو متاثر کیا۔ عوامی status updates میں خرابی کی اندرونی تکنیکی زنجیر نہیں دی گئی اور اسے OpenAI کے routing error کے ساتھ ایک ہی root cause قرار نہیں دیا گیا۔
Grok کا Memphis واقعہ مشترک سبب کیوں ثابت نہیں کرتا
Grok کے status page پر تفتیش تقریباً 06:30 بحرالکاہل وقت پر شروع ہوئی اور 10:05 پر traffic دوبارہ صحت مند قرار دیا گیا۔ آپریٹر کے بعد کے بیان نے Grok کے مسائل کو Memphis compute center کی بندش سے جوڑا، متاثرہ compute partners سے معذرت کی اور تمام systems بحال ہونے کی اطلاع دی۔
The Register کی آزاد رپورٹ نے overlapping اوقات کے ساتھ تین مختلف وضاحتیں درج کیں: OpenAI کا routing error، Anthropic کا infrastructure issue اور Grok سے متعلق Memphis compute-center outage۔ رپورٹ کے وقت Cloudflare نے کسی نمایاں service disruption سے انکار کیا تھا، جبکہ AWS، Google Cloud اور Microsoft Azure کے عوامی dashboards پر بھی ایسی متعلقہ خرابی درج نہیں تھی جو تینوں واقعات کو جوڑتی۔
اس کا مطلب یہ نہیں کہ کوئی مشترک upstream dependency قطعی طور پر ناممکن تھی۔ عوامی dashboards مکمل internal telemetry نہیں دیتے اور updates تاخیر سے بھی آسکتی ہیں؛ تاہم کسی مشترک سبب کے حق میں provider disclosure یا قابلِ تصدیق تکنیکی ثبوت سامنے نہ آنے کی صورت میں محض اتفاقِ وقت سے ایک بڑے cloud failure کا نتیجہ اخذ نہیں کیا جاسکتا۔
کاروباری workflow کے لیے fallback صرف دوسرا model نہیں
پاکستانی software teams، support operations اور AI SaaS کے لیے اس واقعے کا عملی سبق یہ ہے کہ multi-model setup اور حقیقی resilience ایک ہی چیز نہیں۔ اگر بنیادی اور متبادل راستہ ایک authentication service، orchestration layer، network route یا داخلی data pipeline پر منحصر ہو تو provider بدلنے کے باوجود workflow کا مشترک failure point برقرار رہ سکتا ہے۔
ایسی بندش کے لیے ایک محدود fallback template یوں بنایا جاسکتا ہے:
- ہر request کے input، مطلوبہ capability اور processing state کو durable queue میں محفوظ کیا جائے، تاکہ timeout کے بعد کام ضائع یا بلاخبر duplicate نہ ہو۔
- سروس کی صحت API error rate، latency، provider status اور اپنے synthetic checks کے مجموعے سے طے کی جائے؛ صرف صارفین کی شکایات یا ایک dashboard پر انحصار نہ ہو۔
- fallback صرف پہلے سے منظور شدہ provider اور model کی طرف جائے۔ حساس data، retention rules، output format اور quality threshold مختلف ہوں تو خودکار منتقلی روک دی جائے۔
- دونوں راستے ناکام ہوں تو workflow واضح degraded mode اختیار کرے: request queue میں رہے، صارف کو درست حالت دکھائی جائے اور صرف ضروری کام انسانی review کو بھیجے جائیں۔
- بحالی کے بعد backlog کو idempotency controls اور audit log کے ساتھ مرحلہ وار چلایا جائے، تاکہ ایک ہی action دوبارہ انجام نہ پائے اور اچانک load کا نیا مسئلہ پیدا نہ ہو۔
یہ ڈیزائن ہر درخواست کو فوراً کسی دوسرے chatbot پر بھیجنے کی ترکیب نہیں۔ مقصد data loss، غلط model substitution، duplicate actions اور ایسی خاموش ناکامی کو روکنا ہے جس میں interface تو فعال دکھائی دے مگر کاروباری عمل مکمل نہ ہوا ہو۔
کیا ثابت ہوا اور کیا اب بھی نامعلوم ہے
تینوں 3 ستمبر کے واقعات حل ہوچکے ہیں: OpenAI اور Anthropic کے records resolution دکھاتے ہیں، جبکہ Grok سے متعلق بیان میں بھی systems کی بحالی درج ہے۔ ثابت شدہ تصویر تین overlapping disruptions اور تین provider-specific وضاحتوں کی ہے، نہ کہ تصدیق شدہ مشترک outage کی۔
ابھی یہ معلوم نہیں کہ آیا کسی محدود upstream dependency نے ایک سے زیادہ خدمات پر ثانوی اثر ڈالا، یا ایک provider کی بندش کے بعد traffic shifting نے دوسری جگہ load بڑھایا۔ جب تک providers مشترک telemetry یا ایسا post-incident analysis جاری نہیں کرتے جو ان واقعات کی ایک ہی فنی زنجیر دکھائے، انہیں ایک بڑے مشترک cloud failure کا نام دینا دستیاب شواہد سے آگے جانا ہوگا۔
یہ بھی پڑھیں:
ہمارا نیوز لیٹر سبسکرائب کریں
ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔