ChatGPT, Claude i Grok miały problemy niemal równocześnie

Kilka dużych usług AI miało nakładające się problemy 3 września 2026 r.: ChatGPT i Codex od OpenAI, Claude firmy Anthropic oraz Grok od xAI. Zdarzenie zwróciło uwagę, ponieważ użytkownicy konkurencyjnych platform zaczęli zgłaszać kłopoty w tym samym porannym przedziale czasu.

Najważniejszy wniosek wymaga ostrożności: były to równoległe zakłócenia, a nie potwierdzona jedna wspólna awaria. OpenAI wskazało błąd routingu po swojej stronie, natomiast publiczne komunikaty i relacje dotyczące pozostałych usług nie potwierdziły wspólnej przyczyny technicznej. 4041

Jak wyglądał przebieg zdarzeń

Według OpenAI błąd routingu zaczął się około 7:43 czasu pacyficznego (PT) 3 września i sprawił, że ChatGPT oraz Codex były niedostępne dla części użytkowników na różnych platformach. Około 8:17 PT wdrożono rozwiązanie, które było następnie monitorowane. 40

Publiczny incydent na stronie statusowej OpenAI utworzono o 14:58 UTC; opisano go jako „podwyższoną liczbę błędów w ChatGPT i Codex”. 17 Późniejsze zestawienie komunikatów o rozwiązanych incydentach wskazywało, że po stronie OpenAI pełne przywrócenie nastąpiło o 16:55 UTC. Licząc od zgłoszonego początku o 7:43 PT, czyli 14:43 UTC, zakłócenie trwało około 2 godzin i 12 minut. Nie każdy użytkownik odczuł je jednak w takim samym stopniu. 4041

Problemy Anthropic i xAI wystąpiły w tym samym szerszym okresie. Z relacji opartych na ich stronach statusowych wynika, że incydent błędów modeli Anthropic rozwiązano o 16:16 UTC, a xAI poinformowało później, że ruch w Groku wrócił do normy o 17:07 UTC. 41

Co zgłaszali użytkownicy i strony statusowe

Użytkownicy informowali o nieudanych logowaniach, błędach czatu, braku odpowiedzi i problemach z dostępem przez przeglądarkę oraz aplikacje. Dane Downdetectora cytowane podczas zdarzenia pokazały szczególnie duży wzrost zgłoszeń dla ChatGPT: ponad 35 000 w USA. Dla Claude’a było ich ponad 1 400, a dla Groka ponad 1 200. W Indiach odnotowano ponad 2 800 zgłoszeń dotyczących ChatGPT, około 170 Claude’a i ponad 70 Groka. To zgłoszenia użytkowników, a nie pełny pomiar liczby dotkniętych kont, ale wskazują na szeroko zauważalne zakłócenie. 42

Strona statusowa OpenAI potwierdziła podwyższoną liczbę błędów w ChatGPT i Codex, a historia statusu oznaczyła później incydent jako rozwiązany. 1720 Współczesne relacje opisywały problemy z ChatGPT w wersjach internetowej, mobilnej i desktopowej, a nie awarię ograniczoną do jednego interfejsu. 3950

W przypadku Claude’a relacje wskazywały podwyższoną liczbę błędów w kilku modelach, w tym Mythos/Fable 5.1, Mythos/Fable 5, Opus 5, Opus 4.8 i Opus 4.6. Późniejsze aktualizacje mówiły, że wiele modeli wróciło do bazowego poziomu błędów, ale Opus 4.8 i Opus 5 pozostawały dotknięte problemem dłużej. 364749

xAI przyznało, że Grok doświadcza problemów, a późniejsze informacje wskazywały, że ruch usługi ponownie był w normie. 4941

Czy Gemini było działającą alternatywą?

We wczesnych relacjach Google Gemini bywało przedstawiane jako główny konkurent, który pozornie pozostał dostępny, gdy ChatGPT, Claude i Grok miały problemy. Trzeba jednak traktować to zastrzeżeniem. Inne źródła odnotowały zgłoszenia dotyczące Gemini w Downdetectorze, lecz dostępne materiały nie pokazują odpowiadającego im potwierdzonego incydentu po stronie Google. 4448

W praktyce jedna grupa użytkowników może normalnie korzystać z usługi, gdy inna obserwuje zwiększoną liczbę błędów. Serwisy monitorujące awarie są użytecznym sygnałem, ale nie zastępują komunikatu dostawcy ani monitoringu samej aplikacji.

Dlaczego problem wykraczał poza zwykły czat

Dla wielu zespołów konsekwencje nie ograniczają się do możliwości zadania pytania chatbotowi. Niedostępność asystentów programistycznych lub przepływów pracy opartych na agentach może zatrzymać zadania deweloperskie. Błędy API mogą z kolei powodować kolejki, niepowodzenia lub konieczność ręcznej obsługi funkcji produktu i automatyzacji wewnętrznych. Zagrożone są też procesy badawcze wykorzystujące narzędzia do wyszukiwania, syntezy informacji albo długotrwałych zadań.

Historia statusu OpenAI pokazuje szeroki zakres usług, których mogą dotyczyć incydenty platform AI: osobne niedawne komunikaty obejmowały Codex, wyszukiwanie, agentów, Deep Research, konektory, przesyłanie plików, logowanie i procesy zależne od GitHuba. 19242529

Nie oznacza to, że którykolwiek dostawca jest wyjątkowo zawodny. Pokazuje raczej, dlaczego zależność od jednego dostawcy, jednego modelu lub jednego środowiska agentowego może stać się operacyjnym pojedynczym punktem awarii.

Spekulacje o Astra i GPT-6 nie były dowodem

Termin zakłóceń wywołał spekulacje, ponieważ relacje łączyły je z plotkami o nadchodzącym ogłoszeniu OpenAI określanym jako „Astra”, być może związanym z przyszłą generacją modeli GPT-6. Dostępne dowody nie potwierdzają jednak związku przyczynowego.

Wyjaśnieniem OpenAI dla własnego zakłócenia był błąd routingu. Żaden dostawca publicznie nie powiązał równoczesnych problemów z Astrą, GPT-6 ani premierą modelu. Zbieżność czasowa stworzyła nośną narrację, ale nie dowodzi przyczynowości. 403746

Co wcześniejsze incydenty mówią o ryzyku niezawodności

Wydarzenia z 3 września nie były pierwszymi awariami na tym rynku. Historia statusu xAI obejmuje przekroczenie czasu odpowiedzi Grok-2 z 15 stycznia 2025 r., które trwało 3 godziny i 10 minut, a także niedostępność ustrukturyzowanych odpowiedzi dla Grok-2 przez 3 dni i 21 godzin. 23 Historia OpenAI także dokumentuje odrębne incydenty dotyczące zadań Codex, funkcji ChatGPT i procesów związanych z API. 212732

Nie należy wykorzystywać tych zapisów do tworzenia rankingu niezawodności dostawców: dostępne dane nie zawierają porównywalnych definicji przestoju, skali ekspozycji ani liczby dotkniętych użytkowników. Uzasadniają za to węższy wniosek: dla zespołów budujących krytyczne procesy na hostowanych usługach AI awarie są zwykłym ryzykiem, które trzeba uwzględnić w planowaniu.

Praktyczna lista ciągłości działania

Organizacje wykorzystujące AI w pracy produkcyjnej mogą ograniczyć skutki awarii dostawcy, przygotowując się na nią z wyprzedzeniem:

• Stosujcie, tam gdzie to możliwe, interfejsy niezależne od dostawcy, aby aplikacja nie była ściśle związana z formatem żądań i procesami jednej firmy.
• Zdefiniujcie rozwiązania awaryjne dla ważnych zadań: drugiego dostawcę, mniejszy model lokalny, tryb o ograniczonych funkcjach albo procedurę ręczną.
• Bezpiecznie kolejkujcie i ponawiajcie niepilne zadania API, ustawiając limity, które zapobiegają zwielokrotnianiu skutków awarii przez kolejne próby.
• Oddzielcie procesy krytyczne od funkcji pomocniczych. Asystent czatowy może być opcjonalny, ale proces blokujący przegląd kodu, obsługę klienta lub działanie produktu — już nie.
• Testujcie przełączenie awaryjne i ręczne procedury działania. Zapasowy plan, którego nigdy nie przećwiczono, nie jest wiarygodnym planem ciągłości działania.

Zakłócenia z 3 września były nietypowe, ponieważ kilka rozpoznawalnych usług AI sprawiało wrażenie niedostępnych jednocześnie. Szersza lekcja jest jednak prosta: odporność nie polega na przewidywaniu kolejnej awarii, lecz na zaprojektowaniu pracy tak, aby incydent u jednego dostawcy nie zatrzymał kluczowych działań. 41