Störungsverlauf von Memsource

1. 15. Oktober 2026 um 09:44 UTCinvestigating

   Wir untersuchen derzeit ein Problem, das Phrase TMS-Dienste in der EU-Region betrifft, darunter den CAT-Editor, API, Projektmanagement, Translation Memory und verwandte Komponenten. Benutzer können Fehler auftreten oder können zu diesem Zeitpunkt nicht auf diese Dienste zugreifen. Unser Team arbeitet aktiv daran, die Ursache zu identifizieren und die volle Funktionalität so schnell wie möglich wiederherzustellen.

2. 15. Oktober 2026 um 09:58 UTCmonitoring

   Die Dienste haben sich stabilisiert und Phrase TMS in der EU-Region funktioniert jetzt normal. Wir beobachten die Situation weiter.

3. 15. Oktober 2026 um 10:24 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. September 2026 um 08:48 UTCinvestigating

   Einige Benutzer haben möglicherweise Probleme mit dem Zugriff auf Phrase TMS.

2. 23. September 2026 um 08:58 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 23. September 2026 um 09:28 UTCmonitoring

   Der Fix wurde implementiert und wir überwachen die Ergebnisse. Phrase TMS kann jetzt ohne weitere Probleme aufgerufen werden.

4. 23. September 2026 um 10:03 UTCresolved

   Dieser Vorfall wurde behoben.

5. 30. September 2026 um 12:12 UTCpostmortem

   ## Einführung Wir möchten Details zu einem Vorfall mitteilen, der den Zugang zu Phrase TMS am 23. September 2026 beeinträchtigt hat. Zwischen 9:02 Uhr und 11:27 Uhr MESZ konnten Benutzer, die Phrase TMS von Phrase Platform öffnen, die Anmeldung nicht abschließen. Sie wurden entweder in einer Umleitungsschleife gefangen oder mit einem Anmeldefehler auf die Phrase TMS-Anmeldeseite zurückgegeben. Benutzer, die bereits eine aktive Phrase TMS-Sitzung hatten, waren nicht betroffen und es gingen keine Kundendaten verloren oder wurden geändert. Die Anmeldung bei Phrase Platform selbst funktionierte während des gesamten Vorfalls sowohl mit einem Passwort als auch mit Single Sign-On. So hat sich mit einem Passwort direkt auf der Phrase TMS-Anmeldeseite angemeldet. Dieser Post-Mortem erklärt, was passiert ist, wie es gelöst wurde und was wir tun, um zu verhindern, dass es wieder passiert. ## Timeline * **Sep 23, 2026 um 9:02 Uhr CEST** – Ein Update für die Phrase TMS Webanwendung ging live in Produktion. Es beinhaltete eine Sicherheitsverbesserung, wie der Anmeldefluss nach dem Anmelden weiterleitet. Ab diesem Zeitpunkt konnten Benutzer, die Phrase TMS von Phrase Platform öffnen, sich nicht mehr anmelden. Kurz danach wurden die Probleme intern untersucht. * **Sep 23, 2026 um 10:59 Uhr CEST** – Das Update von 9:02 Uhr MESZ wurde als Ursache identifiziert, und wir begannen, ein Rollback vorzubereiten. * **Sep 23, 2026 um 11:13 Uhr CEST** – Der Rollback wurde in unserer Testumgebung verifiziert und der Einsatz in der Produktion gestartet. * **Sep 23, 2026 um 11:27 Uhr CEST** – Der Rollback war in allen Produktionsregionen live. Kundenorientierte Auswirkungen endeten. * ** 23. September 2026 um 11:28 Uhr MESZ ** – Wir haben bestätigt, dass die Anmeldung bei Phrase TMS von Phrase Platform wieder funktioniert hat. * **Sep 23, 2026 um 12:04 Uhr CEST** – Der Vorfall wurde auf unserer Statusseite als gelöst markiert. ## Wurzelursache Der Vorfall wurde durch eine Sicherheitsverbesserung der Phrase TMS-Webanwendung verursacht. Sein Ziel war es, sicherzustellen, dass Benutzer nur an vertrauenswürdige Ziele gesendet werden, nachdem sie sich angemeldet haben. Um dies zu tun, akzeptierte die Webanwendung nur Umleitungen zur Phrase TMS-Webadresse selbst. Wenn ein Benutzer jedoch Phrase TMS von Phrase Platform öffnet, bewegt der Anmeldevorgang den Benutzer legitim zwischen verschiedenen Phrase-Webadressen. Unsere server überprüfen bereits jede dieser umleitungen mit einer liste von vertrauenswürdigen phrase-domains und erlauben sie. Der neue Check in der TMS-Kernanwendung war strenger als dieser serverseitige Check und überschrieb ihn. Infolgedessen wurden legitime Weiterleitungen durch die Phrase TMS-Startseite ersetzt, die den Anmeldeprozess erneut startete. Benutzer haben sich entweder wiederholt angemeldet oder sind mit einem Fehler auf der Phrase TMS-Anmeldeseite gelandet. Die Anmeldung bei Phrase Platform selbst funktionierte während des gesamten Vorfalls sowohl mit einem Passwort als auch mit Single Sign-On. So hat sich mit einem Passwort direkt auf der Phrase TMS-Anmeldeseite angemeldet. Der Fehler ereignete sich bei dem Schritt, bei dem ein angemeldeter Benutzer von der Phrase-Plattform in das Phrase-TSM wechselt. Aus diesem Grund haben einige betroffene Benutzer das Problem als Passwortproblem gemeldet: Sie haben ihre Anmeldeinformationen erfolgreich eingegeben, wurden dann aber an einen Anmeldebildschirm zurückgeschickt. ## Maßnahmen zur Verhinderung von Wiederholungen 1. **Change rollt zurück** – Das Update, das das Problem verursachte, wurde in allen Produktionsregionen um 11:27 Uhr MESZ zurückgesetzt, wodurch die normale Anmeldung wiederhergestellt wurde. 2. **Kontinuierliche Anmeldeüberwachung** – Wir fügen automatisierte Prüfungen hinzu, die regelmäßig in allen Produktionsregionen und in unserer Testumgebung ablaufen. Jede Überprüfung führt die vollständige Anmeldung von Phrase Platform in Phrase TMS durch und benachrichtigt sofort unsere Bereitschaftsingenieure, wenn sie fehlschlägt. Bevor wir uns auf sie verlassen, werden wir bestätigen, dass diese Überprüfungen den genauen Fehler erkennen, der bei diesem Vorfall aufgetreten ist.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 10. September 2026 um 05:06 UTCinvestigating

   Wir untersuchen derzeit ein Problem, das die Synchronisierung von Jobs zwischen Phrase Strings und Phrase TMS über Webhooks in unserer EU-Region betrifft. Kunden können Fehler oder Verzögerungen beim Synchronisieren von Übersetzungsaufträgen zwischen den beiden Produkten feststellen. Unser Team arbeitet aktiv daran, die Ursache zu identifizieren und die volle Funktionalität so schnell wie möglich wiederherzustellen.

2. 10. September 2026 um 05:34 UTCmonitoring

   Ein Fix wurde implementiert und bereitgestellt, um die Webhook-Synchronisationsfehler zwischen Phrase Strings und Phrase TMS zu beheben. Wir beobachten derzeit die Situation, um die volle Stabilität zu bestätigen. Wir werden ein weiteres Update bereitstellen, sobald wir die Entschließung validiert haben.

3. 10. September 2026 um 06:03 UTCresolved

   Wir freuen uns, Ihnen bestätigen zu können, dass das Problem der Webhook-Synchronisation zwischen Phrase Strings und Phrase TMS behoben und als voll funktionsfähig verifiziert wurde, auch für Kunden von US-Rechenzentren. Dieser Vorfall ist nun abgeschlossen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 1. September 2026 um 14:18 UTCinvestigating

   Wir untersuchen derzeit ein Problem, das zu einer Langsamkeit in der Jobs-Ansicht innerhalb von Phrase TMS (EU) führt. Benutzer können verzögerte Ladezeiten oder reduzierte Leistung beim Zugriff auf Projektmanagementfunktionen feststellen. Unser Team arbeitet aktiv daran, die Ursache zu identifizieren und die normale Leistung so schnell wie möglich wiederherzustellen.

2. 1. September 2026 um 15:00 UTCinvestigating

   Wir haben die Ursache des Problems identifiziert. Unser Team implementiert aktiv einen Fix. Wir werden weitere Updates bereitstellen, wenn wir Fortschritte machen.

3. 1. September 2026 um 15:34 UTCmonitoring

   Ein Fix wurde bereitgestellt und wir überwachen die Ergebnisse. Kunden müssen möglicherweise den Browser-Cache löschen und alle geöffneten Registerkarten mit TMS schließen, wenn immer noch Probleme auftreten.

4. 1. September 2026 um 16:23 UTCresolved

   Das Problem wurde gelöst und die Leistung ist stabil.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 31. August 2026 um 15:06 UTCinvestigating

   Wir haben derzeit intermittierende Fehler bei der Kommunikation mit Gengo, einem unserer Drittanbieter von Übersetzungen. Dies führt zu Timeouts und 502 Fehlern bei der Preisberechnung und Auftragseinreichung für Übersetzungsaufträge, die über Gengo geleitet werden und sowohl EU- als auch US-Rechenzentren betreffen. Gengo hat das Problem am Ende bestätigt und untersucht.

2. 2. September 2026 um 11:46 UTCresolved

   Gengo hat das zugrunde liegende Problem an ihrem Ende gelöst. Preisberechnungen und Übersetzungsaufträge an Gengo funktionieren jetzt wieder.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 31. August 2026 um 13:11 UTCinvestigating

   Benutzer sind derzeit nicht in der Lage, bestehende Jobs zu öffnen und neue innerhalb ihrer Phrase TMS-Projekte zu erstellen. Wir untersuchen das Problem.

2. 31. August 2026 um 13:22 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 31. August 2026 um 13:46 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

4. 31. August 2026 um 16:02 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

5. 31. August 2026 um 16:53 UTCresolved

   Das Problem ist gelöst.

6. 4. September 2026 um 08:45 UTCpostmortem

   ## Einführung Wir möchten Details zu einem Vorfall mitteilen, der Phrase TMS am 31. August 2026 betraf. Zwischen 14:26 und 17:57 Uhr MESZ konnten einige Benutzer der Legacy-Projektseite keine Tools-Menüaktionen wie das Erstellen oder Bearbeiten von Jobs und das Ausführen von Analysen verwenden, und das Klicken zum Öffnen eines Jobs startete den CAT-Webeditor nicht wie erwartet, sondern kehrte Benutzer zur Projektseite zurück. Dieser Post-Mortem erklärt, was passiert ist, wie es gelöst wurde und was wir tun, um zu verhindern, dass es wieder passiert. ## Timeline * ** 31. August 2026 um 14:26 Uhr MESZ** – Eine Codeänderung erreichte die Produktion, die einen Defekt enthielt, der die Skriptausführung auf der Projektseite für jeden Benutzer, der sie geladen hatte, brach. * ** 31. August 2026 um 14:49 Uhr MESZ** – In den ersten Kundenberichten wurden Tools-Menü-Buttons als deaktiviert und Jobs im Editor nicht geöffnet. * ** 31. August 2026 um ca. 15:10 Uhr MESZ** – Unser Team hat die Ursache des Problems identifiziert. * ** 31. August 2026 um 15:48 Uhr MESZ ** – Ein Fix für den zugrunde liegenden Defekt wurde abgeschlossen. * ** 31. August 2026 um 16:04 Uhr MESZ** – Der Fix wurde in einer Vorproduktionsumgebung verifiziert. * ** 31. August 2026 um 17:18 Uhr MESZ** – Der Einsatz des Fixes in der Produktion begann. * ** 31. August 2026 um 17:57 Uhr MESZ** – Der Fix war vollständig live in der Produktion und die normale Funktionalität wurde für alle betroffenen Kunden wiederhergestellt. ## Wurzelursache Der Vorfall wurde durch eine Codeänderung verursacht, die ein nicht verwandtes, kleineres Anzeigeproblem auf freigegebenen Projektseiten beheben sollte. Diese Änderung veränderte, wie ein Wert in ein Skript eingefügt wurde, das direkt in die Seite eingebettet ist. Das System, das die Seite darstellt, kodiert automatisch Werte für die Sicherheit, aber diese Codierung unterscheidet nicht zwischen einem Wert, der im regulären Seiteninhalt im Vergleich zu einem Skript platziert wird. Infolgedessen wurde die Syntax des eingebetteten Skripts stillschweigend gebrochen, sobald die Änderung die Produktion erreichte. Da Browser aufhören, weiteren Code auf einer Seite auszuführen, sobald sie auf eine ungültige Skriptsyntax stoßen, wird jedes Skript, das nach diesem Punkt auf der Seite platziert wird, nicht mehr ausgeführt - nicht nur der Teil, der sich auf die ursprüngliche Änderung bezieht. Aus diesem Grund erlebten die Kunden, was wie zwei separate Probleme aussah (deaktivierte Menüschaltflächen und Jobs, die im Editor nicht geöffnet wurden), die tatsächlich nachgelagerte Effekte desselben einzelnen Defekts waren. Das Problem wurde vor der Veröffentlichung nicht erkannt, da die zu diesem Zeitpunkt durchgeführte Überprüfung bestätigte, dass die eingefügten zugrunde liegenden Daten korrekt waren, aber die eigentliche Seite nicht in einen Browser geladen wurde, um zu bestätigen, dass sie Ende-zu-Ende korrekt gerendert und ausgeführt wurde. ## Maßnahmen zur Verhinderung von Wiederholungen 1. **Fix bereitgestellt** – Der zugrunde liegende Defekt wurde am selben Tag, an dem er identifiziert wurde, korrigiert und in die Produktion gebracht. 2. **Ingenieurführung aktualisiert** – Wir haben unsere interne Engineering-Dokumentation aktualisiert, um dieses spezifische Fehlermuster und den richtigen, sicheren Umgang damit klar zu beschreiben, so dass diese Kategorie von Fehlern bei der zukünftigen Code-Überprüfung erfasst wird. 3. **Automatisierte Erkennungsverbesserungen im Gange ** – Wir arbeiten daran, eine automatisierte Überwachung für diese Klasse von Front-End-Ausfällen hinzuzufügen, damit ähnliche Probleme erkannt und behoben werden können, bevor Kunden betroffen sind, anstatt sich auf Kundenberichte zu verlassen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 19. August 2026 um 12:16 UTCinvestigating

   Wir untersuchen derzeit ein Problem mit der Translation Memory-Funktionalität in Phrase TMS (EU). Benutzer können während dieser Zeit Probleme beim Erstellen von Translation Memories und anderen damit verbundenen Vorgängen haben. Unser Team arbeitet aktiv daran, die Ursache zu identifizieren und die volle Funktionalität so schnell wie möglich wiederherzustellen.

2. 19. August 2026 um 12:34 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 19. August 2026 um 13:19 UTCmonitoring

   Es wurde ein Fix umgesetzt, und wir beobachten die Situation.

4. 19. August 2026 um 14:09 UTCresolved

   Der Vorfall wurde behoben.

5. 6. Oktober 2026 um 08:14 UTCpostmortem

   ## **Einführung** Wir möchten mehr Details über die Ereignisse mitteilen, die zwischen 14:11 Uhr MESZ und 16:10 Uhr MESZ am 19. August 2026 stattfanden, was zu einer verschlechterten Translation Memory-Funktionalität in Phrase TMS \(EU\) führte und was Phrase-Ingenieure tun, um zu verhindern, dass sich diese Probleme wiederholen. ## ** Timeline ** * ** 19. August 2026 um 14:11 Uhr MESZ:** Phrase identifizierte ein Problem mit Auswirkungen auf die Translation Memory-Funktionalität in Phrase TMS \(EU\). Benutzer erlebten Fehler beim Erstellen von Translation Memorys und bei der Durchführung verwandter Operationen, einschließlich der Bestätigung von Segmenten, wodurch die Fehlerraten in abhängigen Diensten und Anwendungsfällen erhöht wurden. * ** 19. August 2026 um 14:32 Uhr MESZ:** Die Ursache wurde identifiziert und die Ingenieure begannen, eine Korrektur auf die betroffene Umgebung anzuwenden, indem sie den Cluster neu ausbalancierten und die betroffenen Knoten neu starteten, um die Wiederherstellung zu beschleunigen. * ** 19. August 2026 um 15:10 Uhr MESZ:** Es wurde bestätigt, dass die Erstellung des Translationsgedächtnisses und die damit verbundenen Operationen wieder normal funktionieren. * ** 19. August 2026 um 16:10 Uhr MESZ:** Nachdem eine anhaltende Überwachungsperiode kein Wiederauftreten zeigte, wurde der Vorfall als behoben markiert. ## **Wurzelursache** Die Untersuchung ergab, dass der Vorfall in dem Datenbankcluster entstand, der Translation Memory-Daten speichert. Ein einziges Translation Memory war im Laufe der Zeit sehr groß geworden und erforderte einen überproportionalen Anteil der Leseaktivität, der von dem Knoten bedient werden musste, der auch das Gesundheits- und Metadatenmanagement des breiteren Clusters koordinierte. Da der Cluster über Tage hinweg einer Wartung ohne Ausfallzeiten unterzogen wurde, gab es eine höhere Anzahl von Koordinationsmaßnahmen und eine erhöhte Belastung der Koordinationsknoten im Cluster. Diese beiden kombinierten mit Spitzenlast verursachten eine langsame Verschlechterung der Leistung mehrerer Koordinationsknoten, was zu einer erhöhten Fehlerrate und einer verschlechterten Leistung führte. ## **Aktionen zur Verhinderung von Wiederholungen** Um ähnliche Vorfälle in Zukunft zu verhindern und negative Auswirkungen zu mildern, werden wir: * Den Cluster und seine Backing-Infrastruktur neu ausbalanciert, um mehr Headroom für Translation Memory-Suchen und Updates zu schaffen. * Unterbrechung der laufenden Wartung des betroffenen Translation Memory-Clusters. * Verbesserte Kapazität des Koordinationsknotens und wird die Topologie des Clusters verbessern, um Clusterauswirkungen bei plötzlichen Anfragen zu verhindern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. August 2026 um 07:27 UTCinvestigating

   Wir untersuchen derzeit ein Problem mit Verzweigungsereignissen, die in Phrase Strings (EU) fehlen, was dazu führen kann, dass Änderungen nicht angewendet werden, wenn Zweige zusammengeführt werden.

2. 7. August 2026 um 07:54 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 7. August 2026 um 08:18 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

4. 7. August 2026 um 08:30 UTCmonitoring

   Ein Fix wurde implementiert. Der Rückstand an fehlenden Ereignissen wird nun bearbeitet. Sobald die Warteschlange vollständig verarbeitet ist, erhalten nicht zusammengeführte Zweige automatisch die fehlenden Änderungen. Wir überwachen die Warteschlange und die Ergebnisse.

5. 7. August 2026 um 14:12 UTCresolved

   Änderungen an Zweigen, die während des Ereignisfensters vorgenommen wurden, werden nun vollständig angewendet. Zusammengeführte Niederlassungen, die betroffen waren, wurden identifiziert und betroffene Kunden wurden direkt kontaktiert. Dieser Vorfall wurde behoben.

6. 11. September 2026 um 06:11 UTCpostmortem

   ## Einführung Wir möchten Details zu einem Vorfall mitteilen, der Phrase Strings zwischen dem 6. August und dem 7. August 2026 auf der EU-Plattform betraf. In diesem Zeitraum wurden Änderungen in Zweigstellen nicht von unserer Change-Processing-Pipeline erfasst. Infolgedessen konnten Zweige, die während des Vorfalls zusammengeführt wurden, ohne die während dieses Fensters vorgenommenen Änderungen zusammengeführt werden, und Zweigvergleichsbildschirme konnten keine Unterschiede zeigen, selbst wenn Unterschiede bestanden. Dieser Post-Mortem erklärt, was passiert ist, wie es gelöst wurde und was wir tun, um zu verhindern, dass es wieder passiert. ## Timeline * ** 6. August 2026 um 17:44 Uhr MESZ ** – Eine Netzwerkunterbrechung hat die Verbindung unterbrochen, die unsere Change-Processing-Pipeline zum Lesen von Datenbankänderungen verwendet. Die Verbindung konnte nicht wiederhergestellt werden, und Zweigänderungen wurden nicht mehr verarbeitet. Die betroffene Komponente meldete sich weiterhin als gesund, so dass keine automatisierte Warnung ausgelöst wurde. * **7. August 2026 um 09:11 Uhr CEST** – Das Problem wurde nach einem Kundenbericht identifiziert. * **7. August 2026 um 09:19 Uhr CEST** – Der Vorfall wurde auf unsere höchste Schweregrad eskaliert. * **7. August 2026 um ca. 10:20 Uhr MESZ** – Die betroffene Komponente wurde durch Neustart wiederhergestellt und die Änderungsverarbeitung wurde wieder aufgenommen. * **7. August 2026 um 10:46 Uhr CEST** – Der Auftragsbestand an ausstehenden Änderungen wurde vollständig aufgearbeitet und die Pipeline aufgeholt. * **7. August 2026 Nachmittag** – Die betroffenen Kunden wurden identifiziert und individuell mit den Daten kontaktiert, die zur Wiederherstellung ihrer Änderungen erforderlich sind. ## Wurzelursache Der Vorfall wurde durch eine vorübergehende Netzwerkunterbrechung ausgelöst, die die Verbindung unterbrach, die unser System verwendet, um Änderungen aus der Datenbank in unsere Zweigverarbeitungspipeline zu streamen. Die für diese Verbindung verantwortliche Komponente versuchte, sich automatisch wieder anzuschließen, aber der Wiederverbindungsversuch hing auf unbestimmte Zeit, anstatt entweder erfolgreich zu sein oder zu scheitern. Da die Komponente nie einen Fehler gemeldet hat, wurde der automatische Wiederherstellungsmechanismus unserer Plattform - der Komponenten neu startet, die einen Fehlerzustand melden - nie ausgelöst. Die Komponente blieb in einem Zustand, in dem sie normal zu laufen schien, während sie überhaupt keine Änderungen verarbeitete. Aus diesem Grund hat ein Standardneustart der Verbindung das Problem nicht behoben, während der zugrunde liegende Prozess, der eine neue Verbindung hergestellt hat, vollständig neu gestartet wurde. Die Situation wurde nicht früher erkannt, weil unsere Überwachung für diese Pipeline auf einem Signal beruhte, das während des gesamten Vorfalls weiterhin "gesund" berichtete, und wir hatten kein separates Maß dafür, ob Änderungen tatsächlich durchflossen und verarbeitet wurden. ## Auswirkungen * Zweigstellen, die während des Vorfalls Änderungen hatten, aber **nicht ** zusammengeführt wurden, verloren keine Daten. Ihre Änderungen wurden verarbeitet, sobald sich die Pipeline erholt hatte. * Zweige, die während des Vorfalls zusammengeführt wurden, wurden ohne die während des Vorfallfensters vorgenommenen Änderungen zusammengeführt. Änderungen, die vor dem Vorfall vorgenommen wurden, waren nicht betroffen. * Nur eine kleine Anzahl von Kunden war letztlich betroffen. Jeder wurde individuell kontaktiert und mit den Daten und Schritten versehen, die erforderlich sind, um die betroffenen Änderungen wiederherzustellen. ## Maßnahmen zur Verhinderung von Wiederholungen 1. **Fixed irreführende Überwachung** – Wir korrigierten die Überwachungskonfiguration, die verschiedene Produktionsumgebungen zusammenfasste, was unser Bewusstsein für das Problem verzögert hatte. 2. ** Hinzufügen sinnvoller Gesundheitssignale** – Wir fügen eine Überwachung hinzu, die misst, ob Änderungen tatsächlich durch die Pipeline fließen und wie weit sie zurückliegt, anstatt sich auf ein Statussignal zu verlassen, das "gesund" melden kann, während keine Arbeit geleistet wird. Dies stellt sicher, dass ein ähnlicher Stillstand sofort erkannt wird. 3. **Verbesserung der automatischen Wiederherstellung** – Wir überprüfen das Reconnection- und Retry-Verhalten dieser Komponente, so dass eine geklebte Verbindung zu einem echten Fehler führt, der einen automatischen Neustart auslöst.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 6. August 2026 um 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. August 2026 um 08:18 UTCinvestigating

   We are continuing to investigate this issue.

3. 6. August 2026 um 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. August 2026 um 12:00 UTCmonitoring

   We continue monitoring the situation.

5. 6. August 2026 um 13:19 UTCresolved

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

1. 28. Juli 2026 um 07:19 UTCinvestigating

   Das Engineering-Team identifizierte ein Problem mit Orchestrator, bei dem die neue Workflow-Engine derzeit keine Workflows ausführt. Das Problem wird derzeit untersucht.

2. 28. Juli 2026 um 07:53 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 28. Juli 2026 um 08:30 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

4. 28. Juli 2026 um 08:35 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse. Die Workflow-Engine verarbeitet die Warteschlange der ausstehenden Ausführung.

5. 28. Juli 2026 um 11:49 UTCresolved

   Alle Hinrichtungen wurden bearbeitet. Dieser Vorfall wurde behoben.

6. 30. Juli 2026 um 07:09 UTCpostmortem

   ## Einführung Wir möchten Details zu einem Vorfall mitteilen, der den Phrase Orchestrator vom 27. bis 28. Juli 2026 betroffen hat. Während dieser Zeit konnten Workflow-Ausführungen in der Next-Gen Workflow Engine nicht voranschreiten und blieben in einem "ausführenden" Zustand stecken. Während des Vorfalls gingen keine Daten verloren. Dieses Post-Mortem erklärt, was passiert ist, als es gelöst wurde, und die Schritte, die wir unternommen haben, um eine Wiederholung zu verhindern. ## Timeline * **27 Juli 2026 um 18:55 Uhr CEST** – Die Workflow-Engine begann Fehler zu erzeugen, da die Leistung der Datenbankabfrage verschlechtert wurde. Workflow-Ausführungen blieben stehen und hörten auf, voranzukommen. * **27 Juli 2026 um 20:54 Uhr CEST** – Der erste Kundenbericht über Hinrichtungen, die in "Ausführung" stecken, wurde erhalten. * **27 Juli 2026 um 22:39 Uhr CEST** – Der Vorfall wurde offiziell erklärt. * **28. Juli 2026 um 02:18 Uhr MESZ** – Ein Service-Neustart bot vorübergehende Erleichterung; Workflow-Ausführungen wurden wieder aufgenommen. * **28. Juli 2026 um 05:15 Uhr CEST** – Das Problem trat erneut auf, als das zugrunde liegende Datenbankleistungsproblem fortbestand. * **28. Juli 2026 um 09:56 Uhr CEST** – Die Ursache wurde identifiziert und behoben. Es gingen keine Exekutionen verloren; jedoch wurden aufgrund von teilweisen Dienstneustarts einige Aktionen innerhalb der Exekutionen wiederholt, was dazu geführt haben könnte, dass eine kleine Anzahl von Exekutionen fehlschlug, die sonst erfolgreich gewesen wären. * **28. Juli 2026 um 13:46 Uhr CEST** – Der vollständige Rückstand der ins Stocken geratenen Hinrichtungen wurde als behoben bestätigt. Das System wurde für stabil erklärt. * **28. Juli 2026 um 13:48 Uhr MESZ** – Vorfall behoben. ## Wurzelursache Der Vorfall wurde durch progressive Aufblähungen in Datenbankindizes verursacht, die vom Workflow-Jobplanungssystem verwendet wurden. Die Performance dieser speziellen Indizes verschlechterte sich im Laufe der Zeit allmählich, da sie tote Indexeinträge aus früheren Schreiben und Updates akkumulierten. Die Jobplanungsmaschine erwirbt Koordinationssperren auf Datenbankebene, während sie diese Indizes abfragt, um zu bestimmen, welche Jobs gesendet werden sollen. Da die Index-Lookups langsamer wurden, begannen sie, das konfigurierte Anweisungs-Timeout der Datenbank zu überschreiten. Wenn ein Lookup durch das Timeout abgebrochen wurde, stürzte der für diese Arbeit verantwortliche Planungsprozess ab und wurde neu gestartet. Ohne laufende Scheduler konnten keine Workflow-Schritte versandt werden und alle laufenden Workflow-Ausführungen blieben stecken. Der Datenbankserver selbst blieb während des gesamten Vorfalls gesund, mit normalen CPU- und Verbindungsebenen. Das Problem war ausschließlich Lock- und Latenzkonflikt innerhalb der Planungsschicht. Ein Dienstneustart löschte die abgestürzten Prozesse und stellte die Ausführung vorübergehend wieder her. Da die Indexblähungen jedoch noch vorhanden waren, trat die gleiche Degradation wieder auf, sobald die Abfragelast wieder aufgenommen wurde. Ein manueller Index stellt die vollständig wiederhergestellte Leistung wieder her und behebt das Problem. ## Maßnahmen zur Verhinderung von Wiederholungen 1. **Automatisierte Indexwartung hinzugefügt** – Geplante automatische Indexwartung wurde für die betroffenen Indizes konfiguriert. Dies stellt sicher, dass sich Blähungen im Laufe der Zeit nicht ansammeln können und beseitigt die Bedingungen, die diesen Vorfall ausgelöst haben. 2. **Legacy-Indizes entfernt** – Es wurden nicht verwendete Legacy-Datenbankindizes identifiziert und entfernt, wodurch die gesamte Wartungsfläche reduziert und die zukünftige Indexhygiene vereinfacht wird. 3. **Überwachung der Abdeckung aktualisiert** – Unsere Überwachungslandschaft wird überprüft und aktualisiert, um den aktuellen Zustand der Workflow-Engine widerzuspiegeln. Diese Arbeit wird Lücken schließen, die es ermöglichten, dass die Verschlechterung vor dem ersten Kundenbericht unentdeckt blieb.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 27. Juli 2026 um 23:48 UTCinvestigating

   Engineering hat ein Problem mit Orchestrator identifiziert, bei dem die neue Workflow Engine derzeit keine Workflows ausführt. Das Problem wird derzeit untersucht.

2. 28. Juli 2026 um 00:41 UTCresolved

   Alle Workflows werden wieder wie erwartet ausgeführt.

3. 30. Juli 2026 um 07:08 UTCpostmortem

   ## Einführung Wir möchten Details zu einem Vorfall mitteilen, der den Phrase Orchestrator vom 27. bis 28. Juli 2026 betroffen hat. Während dieser Zeit konnten Workflow-Ausführungen in der Next-Gen Workflow Engine nicht voranschreiten und blieben in einem "ausführenden" Zustand stecken. Während des Vorfalls gingen keine Daten verloren. Dieses Post-Mortem erklärt, was passiert ist, als es gelöst wurde, und die Schritte, die wir unternommen haben, um eine Wiederholung zu verhindern. ## Timeline * **27 Juli 2026 um 18:55 Uhr CEST** – Die Workflow-Engine begann Fehler zu erzeugen, da die Leistung der Datenbankabfrage verschlechtert wurde. Workflow-Ausführungen blieben stehen und hörten auf, voranzukommen. * **27 Juli 2026 um 20:54 Uhr CEST** – Der erste Kundenbericht über Hinrichtungen, die in "Ausführung" stecken, wurde erhalten. * **27 Juli 2026 um 22:39 Uhr CEST** – Der Vorfall wurde offiziell erklärt. * **28. Juli 2026 um 02:18 Uhr MESZ** – Ein Service-Neustart bot vorübergehende Erleichterung; Workflow-Ausführungen wurden wieder aufgenommen. * **28. Juli 2026 um 05:15 Uhr CEST** – Das Problem trat erneut auf, als das zugrunde liegende Datenbankleistungsproblem fortbestand. * **28. Juli 2026 um 09:56 Uhr CEST** – Die Ursache wurde identifiziert und behoben. Es gingen keine Exekutionen verloren; jedoch wurden aufgrund von teilweisen Dienstneustarts einige Aktionen innerhalb der Exekutionen wiederholt, was dazu geführt haben könnte, dass eine kleine Anzahl von Exekutionen fehlschlug, die sonst erfolgreich gewesen wären. * **28. Juli 2026 um 13:46 Uhr CEST** – Der vollständige Rückstand der ins Stocken geratenen Hinrichtungen wurde als behoben bestätigt. Das System wurde für stabil erklärt. * **28. Juli 2026 um 13:48 Uhr MESZ** – Vorfall behoben. ## Wurzelursache Der Vorfall wurde durch progressive Aufblähungen in Datenbankindizes verursacht, die vom Workflow-Jobplanungssystem verwendet wurden. Die Performance dieser speziellen Indizes verschlechterte sich im Laufe der Zeit allmählich, da sie tote Indexeinträge aus früheren Schreiben und Updates akkumulierten. Die Jobplanungsmaschine erwirbt Koordinationssperren auf Datenbankebene, während sie diese Indizes abfragt, um zu bestimmen, welche Jobs gesendet werden sollen. Da die Index-Lookups langsamer wurden, begannen sie, das konfigurierte Anweisungs-Timeout der Datenbank zu überschreiten. Wenn ein Lookup durch das Timeout abgebrochen wurde, stürzte der für diese Arbeit verantwortliche Planungsprozess ab und wurde neu gestartet. Ohne laufende Scheduler konnten keine Workflow-Schritte versandt werden und alle laufenden Workflow-Ausführungen blieben stecken. Der Datenbankserver selbst blieb während des gesamten Vorfalls gesund, mit normalen CPU- und Verbindungsebenen. Das Problem war ausschließlich Lock- und Latenzkonflikt innerhalb der Planungsschicht. Ein Dienstneustart löschte die abgestürzten Prozesse und stellte die Ausführung vorübergehend wieder her. Da die Indexblähungen jedoch noch vorhanden waren, trat die gleiche Degradation wieder auf, sobald die Abfragelast wieder aufgenommen wurde. Ein manueller Index stellt die vollständig wiederhergestellte Leistung wieder her und behebt das Problem. ## Maßnahmen zur Verhinderung von Wiederholungen 1. **Automatisierte Indexwartung hinzugefügt** – Geplante automatische Indexwartung wurde für die betroffenen Indizes konfiguriert. Dies stellt sicher, dass sich Blähungen im Laufe der Zeit nicht ansammeln können und beseitigt die Bedingungen, die diesen Vorfall ausgelöst haben. 2. **Legacy-Indizes entfernt** – Es wurden nicht verwendete Legacy-Datenbankindizes identifiziert und entfernt, wodurch die gesamte Wartungsfläche reduziert und die zukünftige Indexhygiene vereinfacht wird. 3. **Überwachung der Abdeckung aktualisiert** – Unsere Überwachungslandschaft wird überprüft und aktualisiert, um den aktuellen Zustand der Workflow-Engine widerzuspiegeln. Diese Arbeit wird Lücken schließen, die es ermöglichten, dass die Verschlechterung vor dem ersten Kundenbericht unentdeckt blieb.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. Juli 2026 um 12:53 UTCresolved

   Zwischen dem 16. Juni 2026 01:00 Uhr MESZ und dem 17. Juni 2026 11:00 Uhr MESZ erlitt der Phrase Job Sync Connector eine verschlechterte Leistung. Kunden, die den Job Sync mit dem Standardverbindungstyp verwenden, hatten Fehler. Das Ingenieurteam identifizierte eine Ursache und stellte eine Lösung bereit.

2. 20. Juli 2026 um 12:54 UTCpostmortem

   ### Einführung Wir möchten weitere Details zu den Ereignissen mitteilen, die zwischen dem 16. Juni 2026, 13:00 Uhr MESZ und dem 17. Juni 2026, 11:00 Uhr MESZ aufgetreten sind, was zu einer verschlechterten Leistung der Phrase Strings API führte, was dazu führte, dass Kunden, die den Job Sync mit dem Standardverbindungstyp verwendeten, Fehler hatten. Wir entschuldigen uns für die Störung und setzen uns dafür ein, ähnliche Vorfälle in Zukunft zu verhindern. ### Timeline **Juni 16, 2026 @ 01:00 Uhr MESZ** – Job Sync begann fehlgeschlagen für Kunden mit dem Standardverbindungstyp. Konnektoren konnten sich nicht gegen die Phrase Strings API authentifizieren. ** 17. Juni 2026, 10:00 Uhr CEST** – Der Authentifizierungsfehler wurde vom Engineering-Team identifiziert. ** 17. Juni 2026, 10:28 Uhr MESZ** – Der Wirkungsbereich wurde bestätigt: Kunden, die die Standard-Job-Sync-Verbindung verwenden, waren betroffen. Kunden, die persönliche Access-Token-basierte Konnektoren verwenden, waren nicht betroffen. ** 17. Juni 2026, 10:29 Uhr MESZ ** – Die Ursache wurde identifiziert: Eine kürzlich vorgenommene Änderung, die die Unterstützung für Multi-Plattform-Token hinzufügte, führte versehentlich zu Fehlern bei einigen vorhandenen Plattform-Token. ** 17. Juni 2026, 10:40 Uhr MESZ** – Ein Fix wurde vorbereitet und zur Überprüfung eingereicht. ** 17. Juni 2026, 10:53 Uhr CEST** – Der Fix wurde bereitgestellt und die JobSync-Funktionalität wurde vollständig wiederhergestellt. ### Wurzelursache Eine Codeänderung, die eingeführt wurde, um Unterstützung für Multi-Plattform-Authentifizierungstoken hinzuzufügen, hat geändert, wie eingehende Plattformtoken in der Phrase Strings API validiert und verarbeitet werden. Diese Änderung war nicht mit einem vorhandenen Tokenformat kompatibel, das vom Standardverbindungstyp verwendet wurde. Infolgedessen wurden Plattform-Token von der Strings-API mit einer "401 Unauthorized" -Antwort abgelehnt. Der Connector versuchte erneut, die Verbindung herzustellen, bis er sein Retry-Budget erschöpft hatte, wodurch alle betroffenen Operationen fehlschlugen. Kunden, die persönliche Zugangstoken verwenden, waren nicht betroffen, da ihre Token einem anderen Codepfad folgen. ### Maßnahmen zur Verhinderung von Wiederholungen Die Ursache war eine rückwärtskompatible Änderung des Token-Handlings, die während der Entwicklung nicht erkannt wurde. Folgende Maßnahmen werden ergriffen: * **Token-Format-Kompatibilitätstests bei Auth-Änderungen:** Bei der Einführung eines neuen Token-/Authentifizierungsformats neben einem bestehenden müssen Tests explizit den Übergangsfall abdecken - altformatige Token, die unter der neuen Erkennungslogik verarbeitet werden - und nicht nur jedes Format isoliert.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. Juli 2026 um 15:47 UTCinvestigating

   Wir untersuchen derzeit ein Problem, das unseren Metrik-Service betrifft und bei einigen Kunden zu einem doppelten Verbrauch von Metriken führen kann. Unser Team arbeitet aktiv daran, die betroffenen Komponenten zu identifizieren und die Ursache zu bestimmen. Wir werden weitere Updates bereitstellen, sobald weitere Informationen verfügbar sind.

2. 16. Juli 2026 um 16:29 UTCidentified

   Wir haben die Ursache als Instabilität bei einem bestimmten Broker identifiziert, was zu einer wiederholten Neugewichtung der Verbrauchergruppe in unserem Metrik-Service führt und zu einer doppelten Verarbeitung von metrischen Updates führt. Dies kann dazu führen, dass einige Kunden falsche Verbrauchsberechnungen oder eine unerwartete Kontoblockierung erfahren. Wir arbeiten weiter an einem Fix.

3. 16. Juli 2026 um 17:31 UTCmonitoring

   Wir haben den Fortschritt des Problems gestoppt und arbeiten nun daran, den vollen Umfang der Auswirkungen zu identifizieren, einschließlich der betroffenen oder blockierten Organisationen. Betroffene Konten werden für die Auflösung durch einen Deduplizierungsprozess priorisiert, obwohl dies einige Zeit dauern wird.

4. 16. Juli 2026 um 19:04 UTCidentified

   Wir haben den Verbrauch von Metriken für alle blockierten Organisationen erfolgreich dedupliziert. Wir arbeiten weiter daran, Deduplizierungs-Tools pro Organisation zu entwickeln, um genaue Abrechnungszyklusdaten zu gewährleisten, wobei das gesamte Team diese Fixes morgen früh skaliert.

5. 17. Juli 2026 um 13:02 UTCmonitoring

   Wir machen weiterhin Fortschritte bei der Lösung des Problems des doppelten Verbrauchs von Metriken, das erstmals am 16. Juli identifiziert wurde. Die Ursache wurde identifiziert und angegangen. Seit unserem letzten Update hat unser Team die doppelten Daten für alle zuvor gesperrten Konten korrigiert. Wir arbeiten jetzt durch eine verbleibende Reihe von betroffenen Konten und erwarten, dass diese Bereinigung in den kommenden Tagen fortgesetzt wird. Es findet keine weitere Duplikation statt, diese Arbeit befasst sich nur mit historischen Daten.

6. 20. Juli 2026 um 12:07 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. Juli 2026 um 14:49 UTCinvestigating

   Wir untersuchen derzeit ein Problem mit Phrase Orchestrator. Wir arbeiten daran, die Ursache zu identifizieren und werden weitere Updates bereitstellen, sobald weitere Informationen verfügbar sind.

2. 16. Juli 2026 um 15:27 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 16. Juli 2026 um 15:27 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

4. 16. Juli 2026 um 15:41 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

5. 16. Juli 2026 um 16:12 UTCresolved

   Orchestrator (EU) ist seit 17:32 Uhr wieder verfügbar. Alle anhängigen Hinrichtungen werden bearbeitet. Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 10. Juli 2026 um 14:24 UTCinvestigating

   Wir untersuchen derzeit ein Problem, das das Translation Center in Phrase Strings (EU- und US-Regionen) betrifft, wo Strings nicht geladen werden können. Unser Ingenieurteam hat eine mögliche Ursache identifiziert und arbeitet aktiv daran, sie zu beheben. Wir werden weitere Updates bereitstellen, wenn unsere Untersuchung fortschreitet.

2. 10. Juli 2026 um 14:37 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 10. Juli 2026 um 15:24 UTCresolved

   Dieser Vorfall wurde behoben.

4. 7. August 2026 um 07:14 UTCpostmortem

   ## Introduction On July 10, 2026, parts of the Phrase Strings frontend at [app.phrase.com](http://app.phrase.com/) failed to load correctly for a short period, after required stylesheets and scripts failed to load — the underlying service itself stayed available. The issue began at 16:08 CEST and was resolved by 16:27 CEST. This post-mortem explains what happened and what we're doing to prevent a recurrence. ## Timeline * **Jul 10, 2026 at 16:08 CEST** – A deployment introduced new application assets that were never uploaded to our storage service, so the application could no longer load its stylesheets and scripts for customers. * **Jul 10, 2026 at 16:21 CEST** – Issue detected, incident declared. * **Jul 10, 2026 at 16:24 CEST** – Root cause identified. * **Jul 10, 2026 at 16:26 CEST** – Fix applied. * **Jul 10, 2026 at 16:27 CEST** – Customer-facing impact ended. * **Jul 10, 2026 at 16:32 CEST** – Incident downgraded to monitoring while the underlying configuration was addressed. * **Jul 10, 2026 at 17:12 CEST** – Configuration corrected, incident resolved. ## Root Cause During a planned, routine maintenance, a configuration change unintentionally disabled the process that uploads application assets \(stylesheets, scripts\) to our storage and content-delivery service. This went unnoticed at first, since the assets already in place kept working and no new versions had been shipped yet. On July 10, 2026, a deployment shipped new versions of these assets. Because uploading was still disabled, the new files never reached the storage service, and the application could not load its stylesheets and scripts. ## Actions to Prevent Recurrence 1. **Asset synchronization re-enabled** – The disabled process was fixed, restoring correct asset delivery. 2. **Asset availability monitoring** – Adding monitoring to detect asset load failures automatically, before customers are affected.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. Juli 2026 um 12:57 UTCinvestigating

   Wir erhalten Berichte von Benutzern über Jobs, die aus Projekten verschwinden, und wir untersuchen derzeit das Problem.

2. 8. Juli 2026 um 13:08 UTCmonitoring

   Das Problem wurde identifiziert, ein Fix wurde umgesetzt und wir beobachten die Situation.

3. 8. Juli 2026 um 13:55 UTCresolved

   Der Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Juli 2026 um 08:34 UTCinvestigating

   We are currently investigating issues with CAT Web Editor.

2. 7. Juli 2026 um 08:59 UTCmonitoring

   The issue has been identified, a fix was implemented and we are monitoring the situation.

3. 7. Juli 2026 um 09:27 UTCresolved

   The incident has been resolved.

1. 29. Juni 2026 um 07:30 UTCinvestigating

   Hi everyone, this is a test. Please ignore, thank you!

2. 29. Juni 2026 um 08:05 UTCidentified

   Hi everyone, this is a test. Please ignore, thank you!

3. 29. Juni 2026 um 08:09 UTCresolved

   This incident has been resolved.

1. 26. Juni 2026 um 16:19 UTCinvestigating

   Hi everyone, this is a test. Please ignore. Thank you!

1. 26. Juni 2026 um 07:31 UTCinvestigating

   Hello everyone, this is a test. Please ignore, thank you!

2. 26. Juni 2026 um 08:16 UTCinvestigating

   Hello everyone, this is a test. We're "investigating" the issue. Please ignore, thank you!