Störungsverlauf von Memsource

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.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. August 2026 um 07:27 UTCinvestigating

   We are currently investigating an issue with branching events missing in Phrase Strings (EU), which may cause changes to not be applied when branches are merged.

2. 7. August 2026 um 07:54 UTCinvestigating

   We are continuing to investigate this issue.

3. 7. August 2026 um 08:18 UTCidentified

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

4. 7. August 2026 um 08:30 UTCmonitoring

   A fix has been implemented. The backlog of missing events is now being processed. Once the queue is fully processed, unmerged branches will automatically receive the missing changes. We are monitoring the queue and results.

5. 7. August 2026 um 14:12 UTCresolved

   Changes made to branches during the incident window are now fully applied. Merged branches that were affected have been identified and impacted customers have been contacted directly. This incident has been resolved.

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!

1. 26. Juni 2026 um 07:00 UTCinvestigating

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

2. 26. Juni 2026 um 07:02 UTCresolved

   This incident has been resolved.

1. 23. Juni 2026 um 12:53 UTCinvestigating

   Hello everyone, this is a test, kindly ignore.

2. 23. Juni 2026 um 12:57 UTCresolved

   This incident has been resolved.

1. 22. Juni 2026 um 14:16 UTCinvestigating

   This is a test, please ignore.

2. 22. Juni 2026 um 14:21 UTCinvestigating

   This incident has been resolved.