Historia awarii Phraseapp

1. 15 października 2026 09:44 UTCinvestigating

   Obecnie badamy kwestię dotyczącą usług Phrase TMS w regionie UE, w tym edytora CAT, API, zarządzania projektami, pamięci tłumaczeniowej i powiązanych komponentów. Użytkownicy mogą w tym czasie doświadczać błędów lub nie mieć dostępu do tych usług. Nasz zespół aktywnie pracuje nad zidentyfikowaniem przyczyny i jak najszybszym przywróceniem pełnej funkcjonalności.

2. 15 października 2026 09:58 UTCmonitoring

   Usługi ustabilizowały się i Phrase TMS w regionie UE działa obecnie normalnie. Monitorujemy sytuację.

3. 15 października 2026 10:24 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 23 września 2026 08:48 UTCinvestigating

   Niektórzy użytkownicy mogą mieć problemy z dostępem do Phrase TMS.

2. 23 września 2026 08:58 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

3. 23 września 2026 09:28 UTCmonitoring

   Rozwiązanie zostało wdrożone i monitorujemy wyniki. Phrase TMS można teraz uzyskać dostęp bez dalszych problemów.

4. 23 września 2026 10:03 UTCresolved

   Ten incydent został rozwiązany.

5. 30 września 2026 12:12 UTCpostmortem

   # # Wprowadzenie Chcielibyśmy podzielić się szczegółami na temat incydentu, który miał wpływ na dostęp do Phrase TMS 23 września 2026 roku. Między 9: 02 AM a 11: 27 AM CEST, użytkownicy otwierający TMS Phrase z platformy Phrase nie mogli zakończyć logowania. Zostały one albo złapane w pętli przekierowanej lub zwrócone do strony logowania TMS Phrase z znakiem błędu. Użytkownicy, którzy mieli już aktywną sesję Phrase TMS nie zostały naruszone, a dane klienta nie zostały utracone lub zmodyfikowane. Zapisując się do samej platformy Phrase pracował przez cały incydent, zarówno z hasłem i z jednym sygnałem. Tak samo logowanie się z hasłem bezpośrednio na stronie logowania Phrase TMS. To pośmiertne wyjaśnienie tego, co się stało, jak zostało rozwiązane i co robimy, aby zapobiec temu ponownie. # # Timeline * * * 23 września 2026 o 9: 02 CEST * * - Aktualizacja aplikacji internetowej Phrase TMS poszła na żywo w produkcji. Obejmowało to poprawę bezpieczeństwa w jaki sposób uchwyty przepływu sign- in przekierowują się po zalogowaniu. Od tego momentu użytkownicy otwierający Phrase TMS z platformy Phrase nie mogli zakończyć logowania. Krótko po tym, sprawy były badane wewnętrznie. 23 września 2026 o 10: 59 CEST Aktualizacja z 9: 02 rano CEST została zidentyfikowana jako przyczyna, i zaczęliśmy przygotowywać rollback. 23 września 2026 o 11: 13 CEST Cofnięcie zostało zweryfikowane w naszym środowisku testowym i rozpoczęto wdrażanie do produkcji. 23 września 2026 o 11: 27 CEST Rollback był na żywo we wszystkich regionach produkcyjnych. Uderzenie na zamówienie zakończone. * * * 23 września 2026 o 11: 28 AM CEST * * - Potwierdziliśmy, że podpisanie się do Phrase TMS z Phrase Platform działało ponownie. * * * 23 września 2026 o godz. 12: 04 CEST * * - Incydent został zaznaczony jako rozwiązany na naszej stronie statusu. # # Root Cause # Incydent został spowodowany poprawą bezpieczeństwa aplikacji internetowej Phrase TMS. Jego celem było upewnienie się, że użytkownicy są wysyłani do zaufanych miejsc docelowych dopiero po ich zalogowaniu się. Aby to zrobić, aplikacja internetowa akceptuje tylko przekierowanie na sam adres Phrase TMS. Jednak gdy użytkownik otwiera TMS Phrase z platformy Phrase, znak w procesie legalnie przenosi użytkownika między różnymi adresami Phrase web. Nasze serwery już sprawdzają każdy z tych przekierowań z listą zaufanych domen Phrase i pozwalają im. Nowa kontrola w aplikacji podstawowej TMS była bardziej rygorystyczna niż ta kontrola po stronie serwera i ją przekroczyła. W rezultacie, uzasadnione przekierowanie zastąpiono stroną początkową Phrase TMS, która ponownie rozpoczęła proces sygnalizacji. Użytkownicy albo zapętlili się przez sign- in wielokrotnie lub wylądowali z powrotem na stronie logowania Phrase TMS z błędem. Zapisując się do samej platformy Phrase pracował przez cały incydent, zarówno z hasłem i z jednym sygnałem. Tak samo logowanie się z hasłem bezpośrednio na stronie logowania Phrase TMS. Upadek zdarzył się na etapie, gdzie użytkownik signed- in przenosi się z platformy Phrase do Phrase TMS. W związku z tym niektórzy dotknięci użytkownicy zgłosili problem jako problem z hasłem: z powodzeniem wpisali swoje referencje, ale następnie zostali odesłani do ekranu logowania. # # Działania zapobiegające nawrotowi 1. * * Zmiana cofnięta * * - Aktualizacja, która spowodowała ten problem, została cofnięta we wszystkich regionach produkcyjnych o 11: 27 AM CEST, który przywrócił normalne sign-in. 2. * * Ciągły sygnał w monitorowaniu * * - Dodajemy automatyczne kontrole, które są przeprowadzane regularnie we wszystkich regionach produkcyjnych i w naszym środowisku testowym. Każdy czek dokonuje pełnego logowania z platformy Phrase do Phrase TMS i natychmiast alarmuje naszych inżynierów on-call jeśli nie. Zanim na nich polegamy, potwierdzimy, że te kontrole wykryły dokładnie awarię, która miała miejsce w tym incydencie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 10 września 2026 05:06 UTCinvestigating

   Obecnie badamy kwestię wpływającą na synchronizację miejsc pracy między Phrase Strings a Phrase TMS poprzez haki internetowe w naszym regionie UE. Klienci mogą doświadczać niepowodzeń lub opóźnień podczas synchronizowania zadań tłumaczeniowych między dwoma produktami. Nasz zespół aktywnie pracuje nad zidentyfikowaniem przyczyny i jak najszybszym przywróceniem pełnej funkcjonalności.

2. 10 września 2026 05:34 UTCmonitoring

   Zaimplementowano i wdrożono fix w celu usunięcia awarii synchronizacji haka webowego pomiędzy strunami Phrase i TMS Phrase. Obecnie monitorujemy sytuację w celu potwierdzenia pełnej stabilności. Dostarczymy dalsze aktualizacje po zatwierdzeniu rezolucji.

3. 10 września 2026 06:03 UTCresolved

   Z przyjemnością potwierdzimy, że problem synchronizacji haka webowego pomiędzy Phrase Strings i Phrase TMS został rozwiązany i zweryfikowany jako w pełni operacyjny, w tym dla amerykańskich klientów centrum danych. Ten incydent został zamknięty.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 1 września 2026 14:18 UTCinvestigating

   Obecnie badamy problem powodujący powolność w postrzeganiu miejsc pracy w ramach Phrase TMS (UE). Podczas dostępu do funkcji zarządzania projektem użytkownicy mogą mieć opóźniony czas obciążenia lub ograniczoną wydajność. Nasz zespół aktywnie pracuje nad zidentyfikowaniem przyczyny i jak najszybszym przywróceniem normalnej wydajności.

2. 1 września 2026 15:00 UTCinvestigating

   Zidentyfikowaliśmy przyczynę problemu. Nasz zespół aktywnie wprowadza rozwiązanie. Dostarczymy dalsze aktualizacje w miarę postępów.

3. 1 września 2026 15:34 UTCmonitoring

   Ustalono rozwiązanie i monitorujemy wyniki. Klienci mogą być zmuszeni do wyczyszczenia pamięci podręcznej przeglądarki i zamknięcia wszystkich otwartych kart za pomocą TMS, jeśli nadal występują problemy.

4. 1 września 2026 16:23 UTCresolved

   Problem został rozwiązany, a wydajność jest stabilna.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 31 sierpnia 2026 15:06 UTCinvestigating

   Obecnie doświadczamy błędów przerywanych podczas komunikacji z Gengo, jednym z naszych dostawców tłumaczeń trzecich. Powoduje to skróty czasowe i błędy 502 dotyczące obliczania cen oraz składania zamówień na zlecenia tłumaczeniowe kierowane przez Gengo, mające wpływ zarówno na centra danych UE, jak i USA. Gengo potwierdził sprawę i prowadzi śledztwo.

2. 2 września 2026 11:46 UTCresolved

   Gengo rozwiązał kwestię leżącą u ich podstaw. Obliczenia cen i oświadczenia o zamówieniach tłumaczeniowych do Gengo są teraz ponownie pracy.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 31 sierpnia 2026 13:11 UTCinvestigating

   Użytkownicy nie są obecnie w stanie otworzyć istniejących miejsc pracy i stworzyć nowych w ramach swoich projektów Phrase TMS. Badamy tę sprawę.

2. 31 sierpnia 2026 13:22 UTCinvestigating

   Nadal badamy tę kwestię.

3. 31 sierpnia 2026 13:46 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

4. 31 sierpnia 2026 16:02 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

5. 31 sierpnia 2026 16:53 UTCresolved

   Sprawa została rozwiązana.

6. 4 września 2026 08:45 UTCpostmortem

   # # Wprowadzenie Chcielibyśmy podzielić się szczegółami na temat incydentu, który dotknął Phrase TMS 31 sierpnia 2026 roku. Między 2: 26 a 5: 57 PM CEST niektórzy użytkownicy strony projektu nie mogli korzystać z menu Tools-, takich jak tworzenie lub edycja miejsc pracy i wykonywanie analiz, a kliknięcie, aby otworzyć pracę, nie uruchomiło edytora CAT web, jak oczekiwano, zamiast zwracania użytkowników do strony projektu. To pośmiertne wyjaśnienie tego, co się stało, jak zostało rozwiązane i co robimy, aby zapobiec temu ponownie. # # Timeline * * * 31 sierpnia 2026 o 2: 26 PM CEST * * - Zmiana kodu osiągnęła produkcję zawierającą defekt, który przerwał wykonanie skryptu na stronie Projektu dla każdego użytkownika, który go załadował. 31 sierpnia 2026 o 14: 49 CEST Pierwsze raporty klientów zawierały opis przycisków menu Tools- jako wyłączonych i zadań, które nie zostały otwarte w edytorze. * * * 31 sierpnia 2026 r. około 15: 10 CEST * * - Nasz zespół zidentyfikował przyczynę problemu. * * * 31 sierpnia 2026 o 3: 48 PM CEST * * - Naprawiono defekt. 31 sierpnia 2026 o 16: 04 CEST Ustawienie zostało zweryfikowane w środowisku preprodukcyjnym. * * * 31 sierpnia 2026 o 17: 18 CEST * * - Rozpoczęcie procesu produkcji. 31 sierpnia 2026 o 17: 57 CEST Rozwiązanie było w pełni żywe w produkcji i normalna funkcjonalność została przywrócona dla wszystkich klientów dotkniętych. # # Root Cause # Incydent został spowodowany zmianą kodu mającą na celu naprawienie niepowiązanego, niewielkiego problemu z wyświetlaniem na stronach wspólnego projektu. Zmiana ta zmieniła sposób, w jaki wartość została dodana do skryptu osadzonego bezpośrednio na stronie. System, który sprawia, że strona automatycznie koduje wartości bezpieczeństwa, ale kodowanie nie odróżnia wartości umieszczanej w regularnej zawartości strony od wewnątrz skryptu. W rezultacie, składnia wbudowanego skryptu została po cichu złamana, gdy zmiana osiągnęła produkcję. Ponieważ przeglądarki przerywają wykonywanie kolejnych kodów na stronie po napotkaniu nieprawidłowej składni skryptu, każdy skrypt umieszczony po tym punkcie na stronie przestał działać - nie tylko część związana z pierwotną zmianą. Właśnie dlatego klienci doświadczyli tego, co wyglądało jak dwa oddzielne problemy\ (wyłączone przyciski menu i zadania nie otwierają się w edytorze\), które w rzeczywistości były efektami ubocznymi tej samej pojedynczej wady. Kwestia ta nie została wykryta przed wydaniem, ponieważ weryfikacja przeprowadzona w tym czasie potwierdziła, że dane bazowe, które są wstawiane, były prawidłowe, ale nie wczytała rzeczywistej strony w przeglądarce, aby potwierdzić, że została ona wydana i wykonana prawidłowo. # # Działania zapobiegające nawrotowi 1. * * Napraw rozmieszczenie * * - Wada podstawowa została skorygowana i wdrożona do produkcji w tym samym dniu, w którym została zidentyfikowana. 2. * * Aktualizacja wytycznych inżynieryjnych * * - Zaktualizowaliśmy naszą wewnętrzną dokumentację inżynieryjną, aby jasno opisać ten specyficzny wzorzec awarii i poprawny, bezpieczny sposób postępowania z nią, więc ta kategoria błędu jest wyłapywana podczas przeglądu kodu idzie dalej. 3. Pracujemy nad dodaniem zautomatyzowanego monitorowania dla tej klasy niepowodzeń na początku, tak aby podobne kwestie można było wykryć i rozwiązać przed dotknięciem klientów, zamiast polegać na raportach klientów.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 19 sierpnia 2026 12:16 UTCinvestigating

   Obecnie badamy problem wpływający na funkcjonalność pamięci tłumaczeniowej w formacie TMS (UE). Użytkownicy mogą mieć problemy z tworzeniem pamięci tłumaczeniowych i innych powiązanych operacji w tym czasie. Nasz zespół aktywnie pracuje nad zidentyfikowaniem przyczyny i jak najszybszym przywróceniem pełnej funkcjonalności.

2. 19 sierpnia 2026 12:34 UTCidentified

   Problem został zidentyfikowany i wprowadza się rozwiązanie.

3. 19 sierpnia 2026 13:19 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy sytuację.

4. 19 sierpnia 2026 14:09 UTCresolved

   Incydent został rozwiązany.

5. 6 października 2026 08:14 UTCpostmortem

   / Wstęp Chcielibyśmy podzielić się więcej szczegółów na temat wydarzeń, które miały miejsce z Phrase między 2: 11 PM CEST i 4: 10 PM CEST 19 sierpnia 2026, co doprowadziło do degradacji funkcji pamięci tłumaczeniowej w Phrase TMS\ (EU\) i co inżynierowie Phrase robią, aby zapobiec tym problemom ponownie. * * * Timeline * * * * * 19 sierpnia 2026 o 14: 11 CEST: * * Phrase zidentyfikował problem wpływający na funkcjonalność pamięci tłumaczeniowej w Phrase TMS\ (EU\). Użytkownicy doświadczyli błędów podczas tworzenia pamięci tłumaczeniowych i wykonywania powiązanych operacji, w tym potwierdzania segmentów, podnoszenia poziomu błędów w zależności od usług i przypadków wykorzystania. * * * 19 sierpnia 2026 o 14: 32 CEST: * * Zidentyfikowano przyczynę korzenia i inżynierowie zaczęli stosować naprawę do środowiska dotkniętego przez przywrócenie równowagi klastra i ponowne uruchomienie dotkniętych węzłów w celu przyspieszenia odzyskiwania. 19 sierpnia 2026 o 15: 10 CEST: Stworzenie pamięci tłumaczeniowej i związane z nią operacje zostały potwierdzone jako funkcjonujące ponownie normalnie. * * * 19 sierpnia 2026 o 16.10 CEST: * * Po długotrwałym okresie monitorowania nie zaobserwowano nawrotu, incydent został oznaczony jako rozwiązany. * * * Root Cause * * Dochodzenie wykazało, że incydent powstał w bazie danych, która przechowuje dane z pamięci tłumaczeniowej. Pojedyncza pamięć tłumaczeniowa z biegiem czasu bardzo się rozrosła i wymagała nieproporcjonalnego udziału odczytu, który obsługiwał węzeł, który również koordynował zarządzanie zdrowiem i metadanymi szerszego klastra. Ze względu na to, że klaster był poddawany zerowej konserwacji w czasie przestoju dni, była większa ilość działań koordynacyjnych i zwiększone obciążenie węzłów koordynacyjnych w klastrze. Oba te czynniki w połączeniu z szczytowym obciążeniem powodowały powolne pogorszenie wydajności wielu węzłów koordynacyjnych, co doprowadziło do zwiększenia poziomu błędu i pogorszenia wydajności. * * * Actions to Prevent Recurrence * * Aby zapobiec podobnym incydentom w przyszłości i złagodzić negatywne skutki, my: * Zbalansował klaster i jego infrastrukturę back, aby stworzyć więcej miejsca na tłumaczenia pamięci wyszukiwania i aktualizacji. * Wstrzymał się z bieżącą obsługą na wpływającą klaster pamięci tłumaczeniowej. * Poprawa zdolności węzła koordynacyjnego i będzie poprawa topologii klastra, aby zapobiec oddziaływaniu klastra podczas gwałtownych wniosków szczytowych.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 7 sierpnia 2026 07:27 UTCinvestigating

   Obecnie badamy kwestię brakujących zdarzeń rozgałęzieniowych w strunach Phrase (UE), co może spowodować, że zmiany nie będą stosowane w przypadku łączenia oddziałów.

2. 7 sierpnia 2026 07:54 UTCinvestigating

   Nadal badamy tę kwestię.

3. 7 sierpnia 2026 08:18 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

4. 7 sierpnia 2026 08:30 UTCmonitoring

   Zastosowano rozwiązanie. Backlog brakujących zdarzeń jest obecnie przetwarzany. Gdy kolejka zostanie w pełni przetworzona, niepołączone gałęzie automatycznie otrzymają brakujące zmiany. Monitorujemy kolejkę i wyniki.

5. 7 sierpnia 2026 14:12 UTCresolved

   Zmiany w oddziałach podczas okna zdarzenia są teraz w pełni stosowane. Zidentyfikowano połączone oddziały, które ucierpiały, a bezpośrednio skontaktowano się z klientami. Ten incydent został rozwiązany.

6. 11 września 2026 06:11 UTCpostmortem

   # # Wprowadzenie Chcielibyśmy podzielić się szczegółami na temat incydentu, który dotknął Phrase Strings na platformie UE między 6 sierpnia a 7 sierpnia 2026 r. W tym okresie zmiany w oddziałach nie były rejestrowane przez nasz gazociąg do przetwarzania zmian. W rezultacie oddziały, które zostały połączone w czasie incydentu, mogły zostać połączone bez zmian dokonanych w tym oknie, a ekrany porównawcze gałęzi nie wykazywały różnic nawet wtedy, gdy istniały różnice. To pośmiertne wyjaśnienie tego, co się stało, jak zostało rozwiązane i co robimy, aby zapobiec temu ponownie. # # Timeline * * * 6 sierpnia 2026 o 5: 44 PM CEST * * - Przerwa sieciowa przerwała połączenie naszego gazociągu do przetwarzania zmian w bazie danych. Połączenie nie udało się odzyskać, a zmiany gałęzi przestały być przetwarzane. Zagrożony komponent nadal zgłaszał się jako zdrowy, więc nie uruchomiono automatycznego alarmu. 7 sierpnia 2026 o 09: 11 CEST Problem ten został zidentyfikowany po raporcie klienta. * * * 7 sierpnia 2026 o 09: 19 CEST * * - Incydent został wzmożony do naszego najwyższego poziomu ciężkości. * * * 7 sierpnia 2026 roku około 10: 20 CEST * * - Zagrożony składnik odzyskano poprzez ponowne uruchomienie go i wznowiono proces przetwarzania. * * * 7 sierpnia 2026 o 10: 46 CEST * * - Zaległość zmian w toku została w pełni przetworzona, a rurociąg został dogoniony. * * * 7 sierpnia 2026 po południu * * - Zidentyfikowano zainteresowanych klientów i skontaktowano się indywidualnie z danymi niezbędnymi do przywrócenia ich zmian. # # Root Cause # Incydent został wywołany przez przemijające przerwanie sieci, które przerwało połączenie, którego nasz system używa do strumieniowania zmian z bazy danych do naszego rurociągu do przetwarzania branch-. Komponent odpowiedzialny za to połączenie próbował ponownie połączyć się automatycznie, ale próba ponownego połączenia wisiała na czas nieokreślony, a nie powiodła się lub zawiodła. Ponieważ komponent nigdy nie zgłosił awarii, automatyczny mechanizm odzysku naszej platformy - który restartuje komponenty, które zgłaszają stan błędu - nigdy nie został uruchomiony. Składnik pozostał w stanie, w którym wydawał się działać normalnie podczas przetwarzania żadnych zmian. Dlatego też standardowe ponowne uruchomienie połączenia nie rozwiązało problemu, a jednocześnie w pełni uruchomiło proces bazowy, który ustanowił nowe połączenie. Sytuacja nie została wykryta wcześniej, ponieważ nasz monitoring tego rurociągu opierał się na sygnale, który nadal wykazywał "zdrowy" w trakcie całego incydentu, a my nie mieliśmy oddzielnego pomiaru, czy zmiany rzeczywiście przepływają i są przetwarzane. # # Impact * Oddziały, które miały zmiany podczas incydentu, ale nie były * * * połączone nie utraciły żadnych danych. Ich zmiany były przetwarzane po odzyskaniu rurociągu. * Oddziały, które * * zostały połączone podczas incydentu, zostały połączone bez zmian wprowadzonych do nich w oknie incydentu. Zmiany dokonane przed incydentem nie zostały naruszone. * Tylko niewielka liczba klientów została ostatecznie dotknięta. Z każdym skontaktowano się indywidualnie i dostarczono dane oraz kroki niezbędne do przywrócenia dotkniętych zmian. # # Działania zapobiegające nawrotowi 1. * * Naprawiono mylące monitorowanie * * - Naprawiliśmy konfigurację monitorowania, która łączyła różne środowiska produkcyjne, co opóźniło naszą świadomość problemu. 2. * * Dodawanie znaczących sygnałów zdrowotnych * * - Dodamy, że monitorujemy, czy zmiany rzeczywiście płyną przez rurociąg i jak daleko jest za nim, zamiast polegać na sygnale statusu, który może zgłaszać "zdrowy", podczas gdy nie wykonujemy żadnej pracy. Zapewnia to natychmiastowe wykrycie podobnej blokady. 3. * * Poprawa automatycznego odzyskiwania * * - Przeglądamy ponowne połączenie i powtórne zachowanie tego komponentu tak, że zablokowane połączenie powoduje prawdziwą awarię, która uruchamia automatyczne ponowne uruchomienie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 6 sierpnia 2026 08:11 UTCinvestigating

   We are currently investigating an issue affecting Connectors in Phrase TMS. Customers may be unable to access or use Connector functionality during this time. Our engineering team is actively working to identify the cause and restore full service as quickly as possible.

2. 6 sierpnia 2026 08:18 UTCinvestigating

   We are continuing to investigate this issue.

3. 6 sierpnia 2026 08:43 UTCmonitoring

   We have identified the root cause and the issue has now been resolved. Connectors should be appearing as active again. We will continue to monitor the situation to ensure full stability.

4. 6 sierpnia 2026 12:00 UTCmonitoring

   We continue monitoring the situation.

5. 6 sierpnia 2026 13:19 UTCresolved

   The incident has been resolved and all components are back to operational.

1. 28 lipca 2026 07:19 UTCinvestigating

   Zespół inżynieryjny zidentyfikował problem z Orchestratorem, w którym nowy silnik Workflow nie wykonuje obecnie przepływu pracy. Problem jest w trakcie śledztwa.

2. 28 lipca 2026 07:53 UTCinvestigating

   Nadal badamy tę kwestię.

3. 28 lipca 2026 08:30 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

4. 28 lipca 2026 08:35 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki. Silnik przepływu pracy przetwarza kolejkę oczekujących egzekucji.

5. 28 lipca 2026 11:49 UTCresolved

   Wszystkie egzekucje zostały przetworzone. Ten incydent został rozwiązany.

6. 30 lipca 2026 07:09 UTCpostmortem

   # # Wprowadzenie Chcielibyśmy podzielić się szczegółami na temat incydentu, który dotknął Phrase Orchestrator 27 lipca -28, 2026. W tym okresie, egzekucje przepływu pracy w silniku Next- Gen Workflow były niezdolne do postępu i pozostawały w stanie "wykonania". Nie zgubiono żadnych danych podczas incydentu. To pośmiertne wyjaśnienie tego, co się stało, kiedy zostało rozwiązane, i kroki, które podjęliśmy, aby zapobiec nawrotowi. # # Timeline * * * 27 lipca 2026 w 18: 55 CEST * * - Silnik Workflow zaczął produkować błędy w wyniku pogorszenia wydajności zapytania bazy danych. Egzekucje przestały działać. * * * 27 lipca 2026 o 20: 54 CEST * * - Otrzymano pierwszy raport klienta z egzekucji w "wykonaniu". * * * 27 lipca 2026 o 22: 39 CEST * * - Incydent został oficjalnie ogłoszony. * * * 28 lipca 2026 w 02: 18 CEST * * - Ponowne uruchomienie usługi zapewniło tymczasową ulgę; wznowiono egzekucje związane z przepływem pracy. * * * 28 lipca 2026 o 05: 15 CEST * * - Kwestia ta powtórzyła się w miarę utrzymywania się problemu z wydajnością bazy danych. * * * 28 lipca 2026 w 09: 56 CEST * * - Przyczyna została zidentyfikowana i rozwiązana. Egzekucje nie zostały stracone; jednakże z powodu wznowienia usługi częściowej, niektóre działania w ramach egzekucji zostały ponownie przeprowadzone, co mogło spowodować, że niewielka liczba egzekucji nie powiodła się w przeciwnym wypadku. * * * 28 lipca 2026 o 13: 46 CEST * * - Pełne zaległe egzekucje zostały potwierdzone. System został uznany za stabilny. * * * 28 lipca 2026 o 13: 48 CEST * * - Incydent rozwiązany. # # Root Cause # Incydent został spowodowany przez progresywne wzdęcia w indeksach baz danych używanych przez system planowania pracy pracy. Wyniki tych poszczególnych wskaźników stopniowo ulegały degradacji w miarę upływu czasu, ponieważ gromadziły martwe pozycje indeksowe z wcześniejszych pism i aktualizacji. Silnik rozkładania zadań przejmuje zamki koordynacji na poziomie baz danych podczas wyszukiwania tych indeksów w celu określenia, które zadania do wysłania. Wraz z spowolnieniem wyświetlania indeksów, zaczęły one przekraczać skonfigurowany czas zwrotu w bazie danych. Kiedy przeszukanie zostało anulowane przez timeout, proces planowania odpowiedzialny za tę pracę rozbił się i wznowił. Bez uruchomionych terminarzy, nie można było wysłać żadnych etapów przepływu pracy i wszystkie egzekucje przepływu pracy w toku utknęły. Sam serwer bazy danych pozostawał zdrowy przez cały incydent, z normalnym CPU i poziomów połączeń. Problem dotyczył wyłącznie kłótni blokady i opóźnienia w warstwie rozkładu. Ponowne uruchomienie usługi oczyściło uszkodzone procesy i tymczasowo przywróciło wykonanie. Jednakże, ponieważ wskaźnik kwitnienia był nadal obecny, ta sama degradacja powtórzyła się po wznowieniu obciążenia zapytaniem. Ręczny indeks odbudowuje w pełni odrestaurowaną wydajność i rozwiązuje problem. # # Działania zapobiegające nawrotowi 1. * * Dodano automatyczną konserwację indeksu * * - Zaplanowana automatyczna konserwacja indeksu została skonfigurowana dla tych indeksów. Zapewnia to, że wzdęcia nie mogą się gromadzić w czasie i eliminuje warunki, które wywołały ten incydent. 2. * * Usunięte indeksy Legacy * * - Niewykorzystane indeksy bazy danych zostały zidentyfikowane i usunięte, zmniejszając ogólną powierzchnię konserwacji i upraszczając przyszłą higienę indeksu. 3. * * Aktualizacja monitoringu * * - Nasz monitoring jest przeglądany i aktualizowany, aby odzwierciedlać obecny stan silnika przepływu pracy. Prace te zlikwidują luki, które pozwoliły na niewykrycie degradacji przed pierwszym raportem klienta.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 27 lipca 2026 23:48 UTCinvestigating

   Inżynieria zidentyfikowała problem z Orchestratorem, w którym nowy silnik Workflow nie wykonuje obecnie przepływu pracy. Problem jest w trakcie śledztwa.

2. 28 lipca 2026 00:41 UTCresolved

   Wszystkie przepływy pracy są ponownie wykonywane zgodnie z oczekiwaniami.

3. 30 lipca 2026 07:08 UTCpostmortem

   # # Wprowadzenie Chcielibyśmy podzielić się szczegółami na temat incydentu, który dotknął Phrase Orchestrator 27 lipca -28, 2026. W tym okresie, egzekucje przepływu pracy w silniku Next- Gen Workflow były niezdolne do postępu i pozostawały w stanie "wykonania". Nie zgubiono żadnych danych podczas incydentu. To pośmiertne wyjaśnienie tego, co się stało, kiedy zostało rozwiązane, i kroki, które podjęliśmy, aby zapobiec nawrotowi. # # Timeline * * * 27 lipca 2026 w 18: 55 CEST * * - Silnik Workflow zaczął produkować błędy w wyniku pogorszenia wydajności zapytania bazy danych. Egzekucje przestały działać. * * * 27 lipca 2026 o 20: 54 CEST * * - Otrzymano pierwszy raport klienta z egzekucji w "wykonaniu". * * * 27 lipca 2026 o 22: 39 CEST * * - Incydent został oficjalnie ogłoszony. * * * 28 lipca 2026 w 02: 18 CEST * * - Ponowne uruchomienie usługi zapewniło tymczasową ulgę; wznowiono egzekucje związane z przepływem pracy. * * * 28 lipca 2026 o 05: 15 CEST * * - Kwestia ta powtórzyła się w miarę utrzymywania się problemu z wydajnością bazy danych. * * * 28 lipca 2026 w 09: 56 CEST * * - Przyczyna została zidentyfikowana i rozwiązana. Egzekucje nie zostały stracone; jednakże z powodu wznowienia usługi częściowej, niektóre działania w ramach egzekucji zostały ponownie przeprowadzone, co mogło spowodować, że niewielka liczba egzekucji nie powiodła się w przeciwnym wypadku. * * * 28 lipca 2026 o 13: 46 CEST * * - Pełne zaległe egzekucje zostały potwierdzone. System został uznany za stabilny. * * * 28 lipca 2026 o 13: 48 CEST * * - Incydent rozwiązany. # # Root Cause # Incydent został spowodowany przez progresywne wzdęcia w indeksach baz danych używanych przez system planowania pracy pracy. Wyniki tych poszczególnych wskaźników stopniowo ulegały degradacji w miarę upływu czasu, ponieważ gromadziły martwe pozycje indeksowe z wcześniejszych pism i aktualizacji. Silnik rozkładania zadań przejmuje zamki koordynacji na poziomie baz danych podczas wyszukiwania tych indeksów w celu określenia, które zadania do wysłania. Wraz z spowolnieniem wyświetlania indeksów, zaczęły one przekraczać skonfigurowany czas zwrotu w bazie danych. Kiedy przeszukanie zostało anulowane przez timeout, proces planowania odpowiedzialny za tę pracę rozbił się i wznowił. Bez uruchomionych terminarzy, nie można było wysłać żadnych etapów przepływu pracy i wszystkie egzekucje przepływu pracy w toku utknęły. Sam serwer bazy danych pozostawał zdrowy przez cały incydent, z normalnym CPU i poziomów połączeń. Problem dotyczył wyłącznie kłótni blokady i opóźnienia w warstwie rozkładu. Ponowne uruchomienie usługi oczyściło uszkodzone procesy i tymczasowo przywróciło wykonanie. Jednakże, ponieważ wskaźnik kwitnienia był nadal obecny, ta sama degradacja powtórzyła się po wznowieniu obciążenia zapytaniem. Ręczny indeks odbudowuje w pełni odrestaurowaną wydajność i rozwiązuje problem. # # Działania zapobiegające nawrotowi 1. * * Dodano automatyczną konserwację indeksu * * - Zaplanowana automatyczna konserwacja indeksu została skonfigurowana dla tych indeksów. Zapewnia to, że wzdęcia nie mogą się gromadzić w czasie i eliminuje warunki, które wywołały ten incydent. 2. * * Usunięte indeksy Legacy * * - Niewykorzystane indeksy bazy danych zostały zidentyfikowane i usunięte, zmniejszając ogólną powierzchnię konserwacji i upraszczając przyszłą higienę indeksu. 3. * * Aktualizacja monitoringu * * - Nasz monitoring jest przeglądany i aktualizowany, aby odzwierciedlać obecny stan silnika przepływu pracy. Prace te zlikwidują luki, które pozwoliły na niewykrycie degradacji przed pierwszym raportem klienta.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 20 lipca 2026 12:53 UTCresolved

   Między 16 czerwca 2026 01: 00 CEST a 17 czerwca 2026 11: 00 CEST złącze Phrase Job Sync uległo degradacji. Klienci korzystający z Job Sync z domyślnym typem połączenia doświadczyli błędów. Zespół inżynieryjny zidentyfikował przyczynę i dostarczył rozwiązanie.

2. 20 lipca 2026 12:54 UTCpostmortem

   Wstęp Chcielibyśmy podzielić się więcej szczegółów na temat wydarzeń, które miały miejsce z Phrase między 16 czerwca 2026, 01: 00PM CEST i 17 czerwca 2026, 11: 00AM CEST, które doprowadziły do zdegradowanej wydajności Phrase Strings API, co sprawia, że klienci za pomocą Job Sync z domyślnym typem połączenia doświadczyć awarii. Przepraszamy za zakłócenia i jesteśmy zaangażowani w zapobieganie podobnym incydentom w przyszłości. # # Timeline * * Jun 16, 2026 @ 01: 00 PM CEST * * - Job Sync zaczął zawodzić dla klientów używając domyślnego typu połączenia. Złącza nie były w stanie potwierdzić autentyczności przed API strun Phrase. * * 17 czerwca 2026 @ 10: 00 CEST * * - Awaria uwierzytelniania została zidentyfikowana przez zespół inżynierów. * * Jun 17, 2026 @ 10: 28 AM CEST * * - Zakres oddziaływania został potwierdzony: Klienci przy użyciu domyślnego połączenia Job Sync zostały naruszone. Klienci korzystający z osobistego dostępu do złączy opartych na sprzęcie nie byli narażeni. * * Jun 17, 2026 @ 10: 29 AM CEST * * - Zidentyfikowano przyczynę korzeniową: Niedawna zmiana, która niechcący dodała wieloplatformową obsługę symboli. * * Jun 17, 2026 @ 10: 40 AM CEST * * - Naprawa została przygotowana i przedłożona do przeglądu. * * Jun 17, 2026 @ 10: 53 AM CEST Naprawiono go, a funkcjonalność JobSync została w pełni przywrócona. # # Root Cause Zmiana kodu wprowadzona w celu dodania wsparcia dla wieloplatformowych żetonów uwierzytelniających modyfikowanych w jaki sposób przychodzące żetony platformowe są walidowane i przetwarzane w API Strings Phrase. Ta zmiana nie była kompatybilna z istniejącym formatem tokena używanym przez domyślny typ połączenia. W rezultacie, żetony platformy zostały odrzucone przez Strings API z odpowiedzi "401 Nieautoryzowane". Złącze ponownie próbowało ustanowić połączenie aż do wyczerpania swojego budżetu ponownego próby, powodując, że wszystkie dotknięte operacje zawiodły. Klienci korzystający z osobistych żetonów dostępu nie byli narażeni, ponieważ ich żetony podążały inną ścieżką kodu. # # Akcje zapobiegające nawrotowi Podstawową przyczyną była niekompatybilna z tyłu zmiana tokena obsługi, która nie została wykryta podczas rozwoju. Podejmowane są następujące działania: * * * Badanie kompatybilności w formacie Token w zmianach auth: * * Wprowadzając obok istniejącego nowy format tokena / uwierzytelniania, testy muszą wyraźnie obejmować przypadek przejścia - żetony w formacie starym przetwarzane w nowej logice wykrywania - nie tylko każdy format w izolacji.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 16 lipca 2026 15:47 UTCinvestigating

   Obecnie badamy problem wpływający na naszą usługę Metrics, który może skutkować powieleniem zużycia metrycznego dla niektórych klientów. Nasz zespół aktywnie pracuje nad zidentyfikowaniem składników i określeniem przyczyny. Dostarczymy dalsze aktualizacje w miarę dostępności większej ilości informacji.

2. 16 lipca 2026 16:29 UTCidentified

   Zidentyfikowaliśmy przyczynę pierwotną jako niestabilność określonego brokera, co powoduje powtarzające się zrównoważenie grupy konsumentów w naszym serwisie metrycznym i prowadzi do dublowania przetwarzania aktualizacji metrycznych. Może to spowodować, że niektórzy klienci doświadczą nieprawidłowych obliczeń zużycia lub nieoczekiwanego blokowania konta. Pracujemy nad tym.

3. 16 lipca 2026 17:31 UTCmonitoring

   Zatrzymaliśmy postęp problemu i pracujemy teraz nad określeniem pełnego zakresu oddziaływania, w tym jakie organizacje są dotknięte lub zablokowane. Konta dotknięte problemem będą traktowane priorytetowo dla restrukturyzacji i uporządkowanej likwidacji poprzez proces dedukcji, choć zajmie to trochę czasu.

4. 16 lipca 2026 19:04 UTCidentified

   Udało nam się zdeduplikować zużycie danych dla wszystkich zablokowanych organizacji. Kontynuujemy prace nad opracowaniem peroorganizacyjnej dedukcji, aby zapewnić dokładne dane dotyczące cyklu rozliczeń, z pełnym zespołem skalując te poprawki jutro rano.

5. 17 lipca 2026 13:02 UTCmonitoring

   Nadal czynimy postępy w rozwiązywaniu problemu duplikowanej konsumpcji metrycznej, który został po raz pierwszy zidentyfikowany 16 lipca. Przyczyna została zidentyfikowana i rozwiązana. Od naszej ostatniej aktualizacji, nasz zespół skorygował dane dla wszystkich wcześniej zablokowanych kont. Obecnie pracujemy nad pozostałym zbiorem kont, które mają wpływ na sytuację, i oczekujemy, że ten proces oczyszczania będzie kontynuowany w nadchodzących dniach. Nie ma dalszego powielania, prace te dotyczą wyłącznie danych historycznych.

6. 20 lipca 2026 12:07 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 16 lipca 2026 14:49 UTCinvestigating

   Obecnie badamy problem wpływający na Phrase Orchestrator. Pracujemy nad zidentyfikowaniem przyczyny i dostarczymy dalszych aktualizacji, jak tylko więcej informacji będzie dostępnych.

2. 16 lipca 2026 15:27 UTCinvestigating

   Nadal badamy tę kwestię.

3. 16 lipca 2026 15:27 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

4. 16 lipca 2026 15:41 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

5. 16 lipca 2026 16:12 UTCresolved

   Orchestrator (UE) jest dostępny ponownie od 17: 32 PM CEST. Wszystkie egzekucje są w toku. Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 10 lipca 2026 14:24 UTCinvestigating

   Obecnie badamy problem dotykający Centrum Tłumaczeń w Strings Phrase (regiony UE i USA), gdzie struny nie są ładowane. Nasz zespół inżynieryjny zidentyfikował potencjalną przyczynę i aktywnie pracuje nad jej rozwiązaniem. W miarę postępów śledztwa dostarczymy dalsze aktualizacje.

2. 10 lipca 2026 14:37 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

3. 10 lipca 2026 15:24 UTCresolved

   Ten incydent został rozwiązany.

4. 7 sierpnia 2026 07:14 UTCpostmortem

   # # Wprowadzenie W dniu 10 lipca 2026 r. części frontu Phrase Strings znajdują się w [app.phrase.com] (http: / / app.phrase.com /) nie udało się poprawnie załadować przez krótki czas, po tym jak wymagane arkusze stylów i skrypty nie zostały załadowane - sama usługa podstawowa pozostała dostępna. Sprawa zaczęła się o 16: 08 CEST i została rozwiązana o 16: 27 CEST. Ta sekcja wyjaśnia, co się stało i co robimy, by zapobiec nawrotom. # # Timeline * * * Lipiec 10, 2026 o 16: 08 CEST * * - Wprowadzono nowe aktywa aplikacji, które nigdy nie zostały wysłane do naszej usługi przechowywania, więc aplikacja nie mogła już ładować arkuszy stylów i skryptów dla klientów. * * * Lipiec 10, 2026 o 16: 21 CEST * * - Wykryto wydanie, ogłoszono incydent. * * * Lipiec 10, 2026 o 16: 24 CEST * * - Zidentyfikowana przyczyna korzenia. * * * Lip 10, 2026 at 16: 26 CEST * * - Fix applicated. * * * Lip 10, 2026 o 16: 27 CEST * * - zderzenie z dopasowaniem. * * * Lip 10, 2026 at 16: 32 CEST * * - Incydent obniżony do monitorowania, podczas gdy konfiguracja bazowa została skierowana. * * * Lipiec 10, 2026 o 17: 12 CEST * * - Korekta konfiguracji, incydent rozwiązany. # # Root Cause # Podczas planowanej rutynowej konserwacji, zmiana konfiguracji nieumyślnie wyłączyła proces, który wysyła aktywa aplikacji\ (arkusze stylów, skrypty\) do naszej usługi przechowywania i dostarczania treści. Na początku nie było to zauważalne, ponieważ aktywa już na miejscu nadal działały i nie wysłano jeszcze żadnych nowych wersji. W dniu 10 lipca 2026 r. Ponieważ wnoszenie plików było nadal wyłączone, nowe pliki nigdy nie dotarły do usługi przechowywania danych, a aplikacja nie mogła wczytać arkuszy stylów i skryptów. # # Działania zapobiegające nawrotowi 1. * * Synchronizacja aktywów ponownie włączona * * - Proces niepełnosprawności został ustalony, przywracając prawidłową dostawę aktywów. 2. * * Monitoring dostępności aktywów * * - Dodawanie monitorowania w celu wykrycia awarii obciążenia aktywów automatycznie, zanim klienci zostaną dotknięci.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 8 lipca 2026 12:57 UTCinvestigating

   Otrzymujemy raporty od użytkowników na temat zniknięcia miejsc pracy z projektów i obecnie badamy tę kwestię.

2. 8 lipca 2026 13:08 UTCmonitoring

   Zidentyfikowano problem, wdrożono rozwiązanie i monitorujemy sytuację.

3. 8 lipca 2026 13:55 UTCresolved

   Incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 7 lipca 2026 08:34 UTCinvestigating

   Obecnie badamy problemy z CAT Web Editor.

2. 7 lipca 2026 08:59 UTCmonitoring

   Zidentyfikowano problem, wdrożono rozwiązanie i monitorujemy sytuację.

3. 7 lipca 2026 09:27 UTCresolved

   Incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 23 czerwca 2026 12:53 UTCinvestigating

   Hello everyone, this is a test, kindly ignore.

2. 23 czerwca 2026 12:57 UTCresolved

   This incident has been resolved.

1. 22 czerwca 2026 14:16 UTCinvestigating

   This is a test, please ignore.

2. 22 czerwca 2026 14:21 UTCinvestigating

   This incident has been resolved.

3. 22 czerwca 2026 14:34 UTCresolved

   This incident has been resolved.

1. 22 czerwca 2026 11:20 UTCinvestigating

   We are currently investigating an issue affecting Branches functionality in Phrase Strings for customers on our EU data center. Operations on branches may be failing or returning unexpected results. Our engineering team is actively looking into the root cause and will provide further updates as soon as more information is available.

2. 22 czerwca 2026 11:57 UTCinvestigating

   We are continuing to investigate this issue.

3. 22 czerwca 2026 12:40 UTCidentified

   The issue has been identified and a fix is being implemented.

4. 22 czerwca 2026 12:50 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

5. 22 czerwca 2026 13:06 UTCmonitoring

   We are continuing to monitor for any further issues.

6. 22 czerwca 2026 13:07 UTCresolved

   This incident has been resolved.