Historique des pannes de Memsource

1. 15 octobre 2026 à 09:44 UTCinvestigating

   Nous enquêtons actuellement sur un problème touchant les services Phrase TMS dans la région de l'UE, y compris l'éditeur CAT, API, la gestion de projet, la mémoire de traduction et les composants connexes. Les utilisateurs peuvent rencontrer des erreurs ou ne pas avoir accès à ces services pour le moment. Notre équipe s'emploie activement à identifier la cause et à restaurer la pleine fonctionnalité le plus rapidement possible.

2. 15 octobre 2026 à 09:58 UTCmonitoring

   Les services se sont stabilisés et Phrase TMS dans la région de l'UE fonctionne désormais normalement. Nous continuons de surveiller la situation.

3. 15 octobre 2026 à 10:24 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 23 septembre 2026 à 08:48 UTCinvestigating

   Certains utilisateurs pourraient éprouver des problèmes avec l'accès à Phrase TMS.

2. 23 septembre 2026 à 08:58 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 23 septembre 2026 à 09:28 UTCmonitoring

   La correction a été mise en œuvre et nous suivons les résultats. On peut maintenant accéder au SGT de texte sans autre problème.

4. 23 septembre 2026 à 10:03 UTCresolved

   Cet incident a été résolu.

5. 30 septembre 2026 à 12:12 UTCpostmortem

   Présentation Nous aimerions partager des détails sur un incident qui a affecté l'accès à Phrase TMS le 23 septembre 2026. Entre 9h02 et 11h27 CEST, les utilisateurs qui ouvrent Phrase TMS de Phrase Platform n'ont pas pu compléter la connexion. Ils ont été pris dans une boucle de redirection ou retournés à la page de connexion Phrase TMS avec une erreur de connexion. Les utilisateurs qui avaient déjà une session de Phrase TMS active n'ont pas été touchés, et aucune donnée client n'a été perdue ou modifiée. Se connecter à Phrase Platform lui-même a continué à travailler tout au long de l'incident, à la fois avec un mot de passe et avec une seule connexion. Ainsi s'est connecté avec un mot de passe directement sur la page de connexion Phrase TMS. Ce post mortem explique ce qui s'est passé, comment il a été résolu et ce que nous faisons pour l'empêcher de se reproduire. Calendrier * **Sep 23, 2026 à 9h02 CEST** – Une mise à jour de l'application web Phrase TMS est entrée en production. Il a inclus une amélioration de sécurité à la façon dont les poignées de flux de connexion redirige après connexion. À partir de ce moment, les utilisateurs qui ouvrent Phrase TMS de Phrase Platform n'ont pas pu compléter leur connexion. Peu après, les questions ont fait l'objet d'une enquête interne. * **Sep 23, 2026 à 10:59 CEST** – La mise à jour de 9:02 CEST a été identifiée comme la cause, et nous avons commencé à préparer un retour en arrière. * **Sep 23, 2026 à 11h13 CEST** – Le retour a été vérifié dans notre environnement d'essai, et le déploiement à la production a commencé. * **Sep 23, 2026 à 11h27 CEST** – Le recul a été enregistré dans toutes les régions de production. L'impact sur le client a pris fin. * **Sep 23, 2026 à 11:28 CEST** – Nous avons confirmé que la signature à Phrase TMS de Phrase Platform a encore fonctionné. * **Sep 23, 2026 à 12:04 CEST** – L'incident a été marqué comme résolu sur notre page de statut. La cause profonde L'incident a été causé par une amélioration de la sécurité de l'application Web Phrase TMS. Son objectif était de s'assurer que les utilisateurs ne sont envoyés vers des destinations de confiance qu'après leur connexion. Pour ce faire, l'application web n'a accepté que les redirections vers l'adresse web Phrase TMS elle-même. Cependant, lorsqu'un utilisateur ouvre Phrase TMS de Phrase Platform, le processus de connexion déplace légitimement l'utilisateur entre différentes adresses web Phrase. Nos serveurs vérifient déjà chacune de ces redirections sur une liste de domaines Phrase de confiance et les autorisent. La nouvelle vérification dans l'application TMS core était plus stricte que cette vérification côté serveur et l'a dépassée. Par conséquent, les redirections légitimes ont été remplacées par la page de démarrage de Phrase TMS, qui a de nouveau démarré le processus de connexion. Les utilisateurs ont effectué une boucle de connexion à plusieurs reprises ou sont revenus sur la page de connexion Phrase TMS avec une erreur. Se connecter à Phrase Platform lui-même a continué à travailler tout au long de l'incident, à la fois avec un mot de passe et avec une seule connexion. Ainsi s'est connecté avec un mot de passe directement sur la page de connexion Phrase TMS. L'échec s'est produit à l'étape où un utilisateur connecté passe de Phrase Platform à Phrase TMS. Pour cette raison, certains utilisateurs touchés ont signalé le problème comme un problème de mot de passe: ils ont entré leurs identifiants avec succès, mais ont ensuite été renvoyés à un écran de connexion. Actions pour prévenir la récidive 1. **Changement retourné** – La mise à jour qui a causé le problème a été repoussée dans toutes les régions de production à 11:27 CEST, qui a rétabli l'adhésion normale. 2. **Surveillance continue** – Nous ajoutons des contrôles automatisés qui fonctionnent régulièrement dans toutes les régions de production et dans notre environnement de test. Chaque contrôle effectue la connexion complète de Phrase Platform à Phrase TMS et alerte immédiatement nos ingénieurs sur appel si elle échoue. Avant de compter sur eux, nous confirmerons que ces vérifications détectent l'échec exact de cet incident.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 10 septembre 2026 à 05:06 UTCinvestigating

   Nous enquêtons actuellement sur une question ayant une incidence sur la synchronisation des emplois entre Phrase Strings et Phrase TMS via des webhooks dans notre région de l'UE. Les clients peuvent subir des échecs ou des retards lors de la synchronisation des tâches de traduction entre les deux produits. Notre équipe s'emploie activement à identifier la cause fondamentale et à restaurer la pleine fonctionnalité le plus rapidement possible.

2. 10 septembre 2026 à 05:34 UTCmonitoring

   Une correction a été mise en place et déployée pour corriger les défaillances de synchronisation du webhook entre Phrase Strings et Phrase TMS. Nous suivons actuellement la situation pour confirmer la stabilité totale. Nous fournirons une nouvelle mise à jour une fois que nous aurons validé la résolution.

3. 10 septembre 2026 à 06:03 UTCresolved

   Nous sommes heureux de confirmer que le problème de synchronisation entre Phrase Strings et Phrase TMS a été résolu et vérifié comme pleinement opérationnel, y compris pour les clients des centres de données américains. Cet incident est maintenant clos.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 1 septembre 2026 à 14:18 UTCinvestigating

   Nous enquêtons actuellement sur une question qui cause une lenteur dans la perspective des emplois au sein de Phrase TMS (UE). Les utilisateurs peuvent connaître des temps de chargement retardés ou des performances réduites lors de l'accès aux fonctionnalités de gestion de projet. Notre équipe s'emploie activement à identifier la cause profonde et à rétablir des performances normales le plus rapidement possible.

2. 1 septembre 2026 à 15:00 UTCinvestigating

   Nous avons identifié la cause profonde du problème. Notre équipe met en œuvre activement une solution. Nous fournirons d'autres mises à jour à mesure que nous progresserons.

3. 1 septembre 2026 à 15:34 UTCmonitoring

   Un correctif a été déployé et nous suivons les résultats. Les clients pourraient avoir besoin d'effacer le cache du navigateur et fermer tous les onglets ouverts avec TMS si toujours rencontrer des problèmes.

4. 1 septembre 2026 à 16:23 UTCresolved

   Le problème a été résolu et le rendement est stable.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 31 août 2026 à 15:06 UTCinvestigating

   Nous rencontrons actuellement des erreurs intermittentes lors de la communication avec Gengo, l'un de nos fournisseurs de traduction tiers. Cela entraîne des délais et 502 erreurs sur le calcul des prix et la soumission des commandes de traduction acheminées par Gengo, affectant à la fois les centres de données de l'UE et des États-Unis. Gengo a confirmé la question à leur fin et enquête.

2. 2 septembre 2026 à 11:46 UTCresolved

   Gengo a résolu la question sous-jacente à leur fin. Les calculs de prix et les soumissions de commande de traduction à Gengo fonctionnent maintenant à nouveau.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 31 août 2026 à 13:11 UTCinvestigating

   Les utilisateurs sont actuellement incapables d'ouvrir des emplois existants et d'en créer de nouveaux dans le cadre de leurs projets Phrase TMS. Nous enquêtons sur la question.

2. 31 août 2026 à 13:22 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 31 août 2026 à 13:46 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

4. 31 août 2026 à 16:02 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

5. 31 août 2026 à 16:53 UTCresolved

   La question a été réglée.

6. 4 septembre 2026 à 08:45 UTCpostmortem

   Présentation Nous aimerions partager des détails sur un incident qui a touché Phrase TMS le 31 août 2026. Entre 2:26 et 17:57 PM CEST, certains utilisateurs de la page précédente du Projet n'ont pas pu utiliser les actions Tools-menu comme créer ou modifier des tâches et exécuter des analyses, et cliquer pour ouvrir une tâche n'a pas lancé l'éditeur Web CAT comme prévu, au lieu de renvoyer les utilisateurs à la page du projet. Ce post mortem explique ce qui s'est passé, comment il a été résolu et ce que nous faisons pour l'empêcher de se reproduire. Calendrier * **31 août 2026 à 14h26 CEST** – Un changement de code a atteint la production contenant un défaut qui a cassé l'exécution du script sur la page du Projet pour tout utilisateur qui l'a chargé. * **31 août 2026 à 14h49 CEST** – Les premiers rapports clients ont décrit les boutons Tools-menu comme étant désactivés et les emplois qui ne s'ouvrent pas dans l'éditeur. * **Le 31 août 2026 vers 15h10 CEST** – Notre équipe a identifié la cause profonde du problème. * **Le 31 août 2026 à 15h48 CEST** – Une correction du défaut sous-jacent a été effectuée. * **31 août 2026 à 16h04 CEST** – La correction a été vérifiée dans un environnement de préproduction. * **Le 31 août 2026 à 17h18 CEST** – Le déploiement de la fixation à la production a commencé. * **31 août 2026 à 17h57 CEST** – Le fix était entièrement en production et la fonctionnalité normale a été rétablie pour tous les clients touchés. La cause profonde L'incident a été causé par un changement de code visant à corriger un problème d'affichage mineur non lié sur les pages de projet partagées. Ce changement a modifié la façon dont une valeur a été insérée dans un script incorporé directement dans la page. Le système qui rend la page encode automatiquement les valeurs pour la sécurité, mais que l'encodage ne fait pas la distinction entre une valeur placée dans le contenu régulier de la page par rapport à l'intérieur d'un script. En conséquence, la syntaxe du script intégré a été brisée silencieusement une fois le changement atteint la production. Parce que les navigateurs arrêtent l'exécution de tout code supplémentaire sur une page une fois qu'ils rencontrent une syntaxe de script invalide, chaque script placé après ce point sur la page a cessé d'exécuter — pas seulement la partie liée à la modification originale. C'est pourquoi les clients ont connu ce qui ressemblait à deux problèmes séparés \(boutons de menu désactivés et des tâches ne s'ouvrant pas dans l'éditeur\) qui étaient, en fait, des effets en aval du même défaut unique. La question n'a pas été prise avant la publication parce que la vérification effectuée à l'époque a confirmé que les données sous-jacentes étaient correctes, mais n'a pas chargé la page réelle dans un navigateur pour la confirmer rendue et exécutée correctement de bout en bout. Actions pour prévenir la récidive 1. **Fix déployé** – Le défaut sous-jacent a été corrigé et déployé à la production le jour même où il a été identifié. 2. **Directives d ' ingénierie actualisées** Nous avons mis à jour notre documentation d'ingénierie interne pour décrire clairement ce modèle de défaillance spécifique et la façon correcte et sûre de le gérer, de sorte que cette catégorie d'erreur est prise lors de l'examen du code. 3. ** Améliorations de détection automatisées en cours** – Nous travaillons sur l'ajout d'une surveillance automatisée pour cette classe de défaillances frontales, de sorte que des problèmes similaires peuvent être détectés et traités avant que les clients soient touchés, plutôt que de compter sur les rapports des clients.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 19 août 2026 à 12:16 UTCinvestigating

   Nous enquêtons actuellement sur un problème touchant la fonctionnalité de la mémoire de traduction dans Phrase TMS (EU). Les utilisateurs peuvent éprouver des problèmes avec la création de mémoires de traduction et d'autres opérations connexes pendant cette période. Notre équipe s'emploie activement à identifier la cause et à restaurer la pleine fonctionnalité le plus rapidement possible.

2. 19 août 2026 à 12:34 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 19 août 2026 à 13:19 UTCmonitoring

   Un correctif a été mis en place et nous suivons la situation.

4. 19 août 2026 à 14:09 UTCresolved

   L'incident a été résolu.

5. 6 octobre 2026 à 08:14 UTCpostmortem

   **Introduction** Nous aimerions partager plus de détails sur les événements qui se sont produits avec Phrase entre 14h11 CEST et 16h10 CEST le 19 août 2026, ce qui a conduit à la dégradation de la fonctionnalité de la mémoire de traduction dans Phrase TMS \(EU\) et ce que les ingénieurs Phrase font pour empêcher ces problèmes de se reproduire. **Échéancier** * **Le 19 août 2026 à 14 h 11 CEST :** Phrase a identifié un problème affectant la fonctionnalité de la mémoire de traduction dans Phrase TMS \(EU\). Les utilisateurs ont éprouvé des erreurs lors de la création de mémoires de traduction et de l'exécution d'opérations connexes, y compris la confirmation de segments, l'élévation des taux d'erreur pour les services à charge et les cas d'utilisation. * **Le 19 août 2026 à 14 h 32 CEST :** La cause fondamentale a été identifiée et les ingénieurs ont commencé à appliquer une correction à l'environnement touché en rééquilibrant le cluster et en redémarrant les nœuds affectés pour accélérer la récupération. * **Le 19 août 2026 à 15 h 10 CEST :** La création de mémoire de traduction et les opérations connexes ont été confirmées fonctionner à nouveau normalement. * **Le 19 août 2026 à 16 h 10 CEST :** Après une période de surveillance prolongée n'a pas montré de récidive, l'incident a été marqué résolu. ## **La cause de la mort** L'enquête a révélé que l'incident provenait du groupe de bases de données qui stocke les données de la mémoire de traduction. Au fil du temps, une seule mémoire de traduction s'est développée et a exigé qu'une part disproportionnée de l'activité de lecture soit desservie par le nœud qui coordonne également la gestion de la santé et des métadonnées du groupe élargi. Étant donné que le groupe faisait l'objet d'une maintenance à temps zéro pendant des jours, il y avait une plus grande quantité d'actions de coordination et une charge élevée sur les nœuds de coordination dans le groupe. Ces deux facteurs combinés à la charge maximale ont entraîné une détérioration lente de la performance de plusieurs nœuds de coordination, ce qui a entraîné un taux d'erreur élevé et une dégradation de la performance. **Mesures visant à prévenir la récidive** Pour prévenir des incidents semblables à l'avenir et atténuer les effets négatifs, nous : * Rééquilibrer le cluster et son infrastructure de support pour créer plus de salle de tête pour les recherches et les mises à jour de la mémoire de traduction. * L'entretien continu du groupe Mémoire de traduction a été interrompu. * Amélioration de la capacité du noeud de coordination et améliorera la topologie du cluster pour prévenir l'impact des clusters lors des pics de demandes soudaines.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 7 août 2026 à 07:27 UTCinvestigating

   Nous enquêtons actuellement sur un problème lié à l'absence d'événements de branchement dans Phrase Strings (UE), ce qui pourrait faire en sorte que les changements ne soient pas appliqués lorsque les succursales sont fusionnées.

2. 7 août 2026 à 07:54 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 7 août 2026 à 08:18 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

4. 7 août 2026 à 08:30 UTCmonitoring

   Une correction a été mise en œuvre. L'arriéré des événements manquants est en cours de traitement. Une fois la file d'attente entièrement traitée, les branches non fusionnées recevront automatiquement les modifications manquantes. Nous surveillons la file d'attente et les résultats.

5. 7 août 2026 à 14:12 UTCresolved

   Les changements apportés aux succursales pendant la fenêtre des incidents sont maintenant pleinement appliqués. Les succursales fusionnées qui ont été touchées ont été identifiées et les clients touchés ont été contactés directement. Cet incident a été résolu.

6. 11 septembre 2026 à 06:11 UTCpostmortem

   Présentation Nous aimerions partager des détails sur un incident qui a touché Phrase Strings sur la plate-forme de l'UE entre le 6 et le 7 août 2026. Au cours de cette période, les changements apportés aux succursales n'ont pas été enregistrés par notre pipeline de transformation. Par conséquent, les succursales qui ont été fusionnées pendant l'incident pourraient être fusionnées sans les changements qui leur ont été apportés pendant cette fenêtre, et les écrans de comparaison des succursales ne pouvaient montrer aucune différence même lorsque des différences existaient. Ce post mortem explique ce qui s'est passé, comment il a été résolu et ce que nous faisons pour l'empêcher de se reproduire. Calendrier * **Le 6 août 2026 à 17h44 CEST** – Une interruption du réseau a coupé la connexion que notre pipeline de traitement de changement utilise pour lire les changements de base de données. La connexion n'a pas réussi à récupérer, et les changements de branche ont cessé d'être traités. La composante touchée a continué de se déclarer saine, de sorte qu'aucune alerte automatisée n'a été déclenchée. * **Le 7 août 2026 à 9h11 CEST** – Le problème a été identifié à la suite d'un rapport de client. * **Le 7 août 2026 à 9 h 19 CEST** – L'incident a été augmenté à notre plus haut niveau de gravité. * **Le 7 août 2026 vers 10h20 CEST** – La composante touchée a été récupérée en la redémarrant et le traitement des changements a repris. * **Le 7 août 2026 à 10h46 CEST** – L'arriéré des changements en suspens a été entièrement traité et le pipeline a été rattrapé. * **Le 7 août 2026 après-midi** – Les clients touchés ont été identifiés et contactés individuellement avec les données nécessaires pour restaurer leurs changements. La cause profonde L'incident a été déclenché par une interruption transitoire du réseau qui a brisé la connexion que notre système utilise pour transférer les changements de la base de données vers notre pipeline de traitement de succursales. Le composant responsable de cette connexion a tenté de se reconnecter automatiquement, mais la tentative de reconnection a été suspendue indéfiniment plutôt que de réussir ou d'échouer. Comme le composant n'a jamais signalé de défaillance, le mécanisme de récupération automatique de notre plateforme, qui redémarre les composants qui signalent un état d'erreur, n'a jamais été déclenché. La composante est restée dans un état où elle semblait fonctionner normalement tout en ne traitant aucun changement. C'est pourquoi un redémarrage standard de la connexion n'a pas résolu le problème, tout en redémarrant complètement le processus sous-jacent, qui a établi une nouvelle connexion. La situation n'a pas été décelée plus tôt parce que notre surveillance de ce pipeline s'est appuyée sur un signal qui a continué de signaler « sainement » tout au long de l'incident, et nous n'avions pas de mesure distincte pour déterminer si les changements se sont réellement produits et ont été traités. Impact * Les branches qui ont subi des changements pendant l'incident mais qui n'ont pas été fusionnées** n'ont pas perdu de données. Leurs modifications ont été traitées une fois le pipeline récupéré. * Les branches qui **ont été** fusionnées pendant l'incident ont été fusionnées sans les changements qui leur ont été apportés pendant la fenêtre de l'incident. Les changements apportés avant l'incident n'ont pas été touchés. * Seul un petit nombre de clients ont finalement été touchés. Chacun d'eux a été contacté individuellement et a fourni les données et les étapes nécessaires pour restaurer les changements touchés. Actions pour prévenir la récidive 1. **Surveillance fictive** – Nous avons corrigé la configuration de surveillance qui a regroupé différents environnements de production, ce qui avait retardé notre prise de conscience de la question. 2. **Ajouter des signaux significatifs en matière de santé** – Nous ajoutons que nous mesurons si les changements passent par le pipeline et jusqu'à quel point il est en retard, plutôt que de nous appuyer sur un signal de statut qui peut déclarer « sain » alors qu'aucun travail n'est fait. Cela permet de détecter immédiatement un décrochage similaire. 3. ** Amélioration de la récupération automatique** – Nous examinons le comportement de reconnection et de réessayer de ce composant afin qu'une connexion bloquée entraîne une véritable défaillance qui déclenche le redémarrage automatique.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 6 août 2026 à 08:11 UTCinvestigating

   Nous enquêtons actuellement sur un problème touchant les connecteurs dans Phrase TMS. Les clients peuvent être incapables d'accéder ou d'utiliser la fonctionnalité Connector pendant cette période. Notre équipe d'ingénieurs s'emploie activement à identifier la cause et à rétablir le service complet le plus rapidement possible.

2. 6 août 2026 à 08:18 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 6 août 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 août 2026 à 12:00 UTCmonitoring

   We continue monitoring the situation.

5. 6 août 2026 à 13:19 UTCresolved

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

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 28 juillet 2026 à 07:19 UTCinvestigating

   L'équipe d'ingénierie a identifié un problème avec Orchestrator où le nouveau Workflow Engine n'exécute actuellement pas de workflows. Le problème est en cours d'enquête.

2. 28 juillet 2026 à 07:53 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 28 juillet 2026 à 08:30 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

4. 28 juillet 2026 à 08:35 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats. Le moteur de flux de travail traite la file d'attente des exécutions en attente.

5. 28 juillet 2026 à 11:49 UTCresolved

   Toutes les exécutions ont été traitées. Cet incident a été résolu.

6. 30 juillet 2026 à 07:09 UTCpostmortem

   Présentation Nous aimerions partager des détails sur un incident qui a touché Phrase Orchestrator les 27 et 28 juillet 2026. Au cours de cette période, les exécutions de workflow dans le Next-Gen Workflow Engine n'ont pas pu progresser et sont restées coincées dans un état « d'exécution ». Aucune donnée n'a été perdue pendant l'incident. Ce post-mortem explique ce qui s'est passé, quand il a été résolu, et les mesures que nous avons prises pour empêcher une récurrence. Calendrier * **27 juillet 2026 à 18 h 55 CEST** – Le moteur de flux de travail a commencé à produire des erreurs lorsque la performance de la requête de base de données s'est dégradée. Les exécutions de flux de travail ont bloqué et cessé de progresser. * **27 juillet 2026 à 20:54 CEST** – Le premier rapport de client sur les exécutions coincées dans "exécution" a été reçu. * **27 juillet 2026 à 22:39 CEST** – L'incident a été officiellement déclaré. * **28 juillet 2026 à 02:18 CEST** – Un redémarrage du service a fourni un soulagement temporaire; les exécutions de workflow ont repris. * **28 juillet 2026 à 05 h 15 CEST** – La question a repris à mesure que le problème sous-jacent de performance de la base de données persistait. * **28 juillet 2026 à 09:56 CEST** – La cause profonde a été identifiée et traitée. Aucune exécution n'a été perdue; toutefois, en raison de la reprise partielle du service, certains actes au sein de l'exécution ont été relancés, ce qui a peut-être causé l'échec d'un petit nombre d'exécutions qui auraient autrement réussi. * **28 juillet 2026 à 13:46 CEST** – L ' arriéré total d ' exécutions bloquées a été confirmé comme étant réglé. Le système a été déclaré stable. * **28 juillet 2026 à 13 h 48 CEST** – L'incident est réglé. La cause profonde L'incident a été causé par le gonflement progressif des index des bases de données utilisés par le système de planification des tâches. La performance de ces indices particuliers s'est progressivement dégradée au fil du temps en accumulant les entrées d'indices morts provenant d'écritures et de mises à jour antérieures. Le moteur de planification des tâches acquiert des verrous de coordination au niveau de la base de données tout en interrogeant ces index pour déterminer les tâches à envoyer. À mesure que la recherche d'index augmentait plus lentement, ils ont commencé à dépasser le délai d'attente de la déclaration configurée de la base de données. Lorsqu'une recherche a été annulée par le timeout, le processus de planification responsable de ce travail s'est écrasé et a redémarré. En l'absence de planificateurs, aucune étape du workflow n'a pu être envoyée et toutes les exécutions en cours sont devenues bloquées. Le serveur de base de données lui-même est resté sain tout au long de l'incident, avec un processeur normal et des niveaux de connexion. Le problème était exclusivement la dispute de verrouillage et de latence dans la couche de programmation. Un redémarrage du service a permis d'effacer les processus écrasés et de rétablir temporairement l'exécution. Cependant, comme l'index bloat était toujours présent, la même dégradation a repris une fois la charge de requête reprise. Un index manuel reconstitue complètement les performances et résout le problème. Actions pour prévenir la récidive 1. ** Maintenance de l'index automatique ajoutée** – La maintenance de l'index automatique programmée a été configurée pour les index concernés. Cela garantit que le ballonnement ne peut pas s'accumuler au fil du temps et élimine les conditions qui ont déclenché cet incident. 2. **Les index des bases de données inutilisés ont été identifiés et supprimés, ce qui a réduit la surface d'entretien globale et simplifié l'hygiène future des index. 3. ** Mise à jour du suivi** – Notre paysage de surveillance est en cours d'examen et de mise à jour pour refléter l'état actuel du moteur de travail. Ce travail permettra de combler les lacunes qui ont permis à la dégradation de passer inaperçue avant le premier rapport client.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 27 juillet 2026 à 23:48 UTCinvestigating

   L'ingénierie a identifié un problème avec Orchestrator où le nouveau Workflow Engine n'exécute pas actuellement de workflows. Le problème est en cours d'enquête.

2. 28 juillet 2026 à 00:41 UTCresolved

   Tous les workflows sont exécutés à nouveau comme prévu.

3. 30 juillet 2026 à 07:08 UTCpostmortem

   Présentation Nous aimerions partager des détails sur un incident qui a touché Phrase Orchestrator les 27 et 28 juillet 2026. Au cours de cette période, les exécutions de workflow dans le Next-Gen Workflow Engine n'ont pas pu progresser et sont restées coincées dans un état « d'exécution ». Aucune donnée n'a été perdue pendant l'incident. Ce post-mortem explique ce qui s'est passé, quand il a été résolu, et les mesures que nous avons prises pour empêcher une récurrence. Calendrier * **27 juillet 2026 à 18 h 55 CEST** – Le moteur de flux de travail a commencé à produire des erreurs lorsque la performance de la requête de base de données s'est dégradée. Les exécutions de flux de travail ont bloqué et cessé de progresser. * **27 juillet 2026 à 20:54 CEST** – Le premier rapport de client sur les exécutions coincées dans "exécution" a été reçu. * **27 juillet 2026 à 22:39 CEST** – L'incident a été officiellement déclaré. * **28 juillet 2026 à 02:18 CEST** – Un redémarrage du service a fourni un soulagement temporaire; les exécutions de workflow ont repris. * **28 juillet 2026 à 05 h 15 CEST** – La question a repris à mesure que le problème sous-jacent de performance de la base de données persistait. * **28 juillet 2026 à 09:56 CEST** – La cause profonde a été identifiée et traitée. Aucune exécution n'a été perdue; toutefois, en raison de la reprise partielle du service, certains actes au sein de l'exécution ont été relancés, ce qui a peut-être causé l'échec d'un petit nombre d'exécutions qui auraient autrement réussi. * **28 juillet 2026 à 13:46 CEST** – L ' arriéré total d ' exécutions bloquées a été confirmé comme étant réglé. Le système a été déclaré stable. * **28 juillet 2026 à 13 h 48 CEST** – L'incident est réglé. La cause profonde L'incident a été causé par le gonflement progressif des index des bases de données utilisés par le système de planification des tâches. La performance de ces indices particuliers s'est progressivement dégradée au fil du temps en accumulant les entrées d'indices morts provenant d'écritures et de mises à jour antérieures. Le moteur de planification des tâches acquiert des verrous de coordination au niveau de la base de données tout en interrogeant ces index pour déterminer les tâches à envoyer. À mesure que la recherche d'index augmentait plus lentement, ils ont commencé à dépasser le délai d'attente de la déclaration configurée de la base de données. Lorsqu'une recherche a été annulée par le timeout, le processus de planification responsable de ce travail s'est écrasé et a redémarré. En l'absence de planificateurs, aucune étape du workflow n'a pu être envoyée et toutes les exécutions en cours sont devenues bloquées. Le serveur de base de données lui-même est resté sain tout au long de l'incident, avec un processeur normal et des niveaux de connexion. Le problème était exclusivement la dispute de verrouillage et de latence dans la couche de programmation. Un redémarrage du service a permis d'effacer les processus écrasés et de rétablir temporairement l'exécution. Cependant, comme l'index bloat était toujours présent, la même dégradation a repris une fois la charge de requête reprise. Un index manuel reconstitue complètement les performances et résout le problème. Actions pour prévenir la récidive 1. ** Maintenance de l'index automatique ajoutée** – La maintenance de l'index automatique programmée a été configurée pour les index concernés. Cela garantit que le ballonnement ne peut pas s'accumuler au fil du temps et élimine les conditions qui ont déclenché cet incident. 2. **Les index des bases de données inutilisés ont été identifiés et supprimés, ce qui a réduit la surface d'entretien globale et simplifié l'hygiène future des index. 3. ** Mise à jour du suivi** – Notre paysage de surveillance est en cours d'examen et de mise à jour pour refléter l'état actuel du moteur de travail. Ce travail permettra de combler les lacunes qui ont permis à la dégradation de passer inaperçue avant le premier rapport client.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 20 juillet 2026 à 12:53 UTCresolved

   Entre le 16 juin, 2026 01:00PM CEST et le 17 juin, 2026 11:00AM CEST, le connecteur Phrase Job Sync a subi des performances dégradées. Les clients utilisant le Job Sync avec le type de connexion par défaut ont subi des défaillances. L'équipe d'ingénierie a identifié une cause profonde et a fourni une solution.

2. 20 juillet 2026 à 12:54 UTCpostmortem

   Introduction Nous aimerions partager plus de détails sur les événements qui se sont produits avec Phrase entre le 16 juin, 2026, 01:00PM CEST et le 17 juin, 2026, 11:00AM CEST, qui ont conduit à la dégradation des performances de Phrase Strings API, provoquant des clients utilisant le Job Sync avec le type de connexion par défaut pour éprouver des défaillances. Nous nous excusons de cette perturbation et nous nous engageons à prévenir des incidents semblables à l'avenir. Calendrier **Jun 16, 2026 @ 13:00 CEST** – Job Sync a commencé à échouer pour les clients en utilisant le type de connexion par défaut. Les connecteurs n'ont pas pu s'authentifier contre l'API des cordes Phrase. **Jun 17, 2026 @ 10h00 CEST** – L'équipe d'ingénierie a identifié l'échec de l'authentification. **Jun 17, 2026 @ 10:28 CEST** – La portée de l'impact a été confirmée : les clients utilisant la connexion Job Sync par défaut ont été affectés. Les clients utilisant des connecteurs à jeton d'accès personnel n'ont pas été touchés. **Jun 17, 2026 @ 10:29 CEST** – La cause racine a été identifiée: Un changement récent qui a ajouté le support de jetons multi-plateforme introduit par inadvertance des erreurs avec certains jetons de plate-forme existants. **Jun 17, 2026 @ 10:40 CEST** – Une correction a été préparée et soumise pour examen. **Jun 17, 2026 @ 10:53 CEST** – La correction a été déployée et la fonctionnalité JobSync a été entièrement restaurée. Cause profonde Un changement de code introduit pour ajouter une prise en charge des jetons d'authentification multi-plateforme a modifié comment les jetons de plate-forme entrants sont validés et traités dans l'API Phrase Strings. Ce changement n'était pas compatible avec un format de jeton existant utilisé par le type de connexion par défaut. En conséquence, les jetons de plate-forme ont été rejetés par l'API Strings avec une réponse `401 non autorisée`. Le connecteur a réévalué l'installation de la connexion jusqu'à épuiser son budget de réessayer, ce qui a causé l'échec de toutes les opérations concernées. Les clients utilisant des jetons d'accès personnels n'ont pas été affectés car leurs jetons suivent un chemin de code différent. Actions visant à prévenir la récidive La cause principale était un changement incompatible par rapport à la manipulation des jetons qui n'a pas été détecté pendant le développement. Les mesures suivantes sont prises : * **Test de compatibilité au format symbolique dans les modifications d'auth :** Lors de l'introduction d'un nouveau format de jeton/authentification à côté d'un format existant, les tests doivent explicitement couvrir le cas de transition — les jetons anciens étant traités sous la nouvelle logique de détection — et pas seulement chaque format isolé.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 juillet 2026 à 15:47 UTCinvestigating

   Nous enquêtons actuellement sur un problème touchant notre service de métriques qui pourrait entraîner une consommation de métriques dupliquée pour certains clients. Notre équipe travaille activement à identifier les composants touchés et à déterminer la cause profonde. Nous fournirons d'autres mises à jour à mesure que de plus amples renseignements seront disponibles.

2. 16 juillet 2026 à 16:29 UTCidentified

   Nous avons identifié la cause fondamentale comme l'instabilité sur un courtier spécifique, ce qui provoque un rééquilibrage répété du groupe de consommateurs dans notre service de métriques et conduit au traitement double des mises à jour métriques. Cela peut entraîner chez certains clients des calculs de consommation incorrects ou un blocage inattendu du compte. Nous continuons à travailler sur une solution.

3. 16 juillet 2026 à 17:31 UTCmonitoring

   Nous avons arrêté la progression de la question et nous nous efforçons maintenant d'identifier toute la portée de l'impact, y compris les organisations qui sont touchées ou bloquées. Les comptes affectés seront classés par ordre de priorité aux fins de résolution au moyen d'un processus de déduplication, même si cela prendra un certain temps à terminer.

4. 16 juillet 2026 à 19:04 UTCidentified

   Nous avons réussi à dédoubler la consommation de mesures pour toutes les organisations bloquées. Nous poursuivons nos travaux pour mettre au point des outils de déduplication par organisation afin d'assurer l'exactitude des données du cycle de facturation, avec l'échelle complète de ces correctifs demain matin.

5. 17 juillet 2026 à 13:02 UTCmonitoring

   Nous continuons de faire des progrès pour résoudre le problème de consommation de mesures dupliquées, identifié pour la première fois le 16 juillet. La cause profonde a été identifiée et traitée. Depuis notre dernière mise à jour, notre équipe a corrigé les données dupliquées pour tous les comptes précédemment bloqués. Nous travaillons maintenant sur un ensemble de comptes affectés restants et nous nous attendons à ce que ce nettoyage se poursuive au cours des prochains jours. Il n'y a plus de duplication, ce travail ne porte que sur les données historiques.

6. 20 juillet 2026 à 12:07 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 juillet 2026 à 14:49 UTCinvestigating

   Nous enquêtons actuellement sur un problème touchant Phrase Orchestrator. Nous nous efforçons d'identifier la cause fondamentale et fournirons d'autres mises à jour dès que de plus amples renseignements seront disponibles.

2. 16 juillet 2026 à 15:27 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 16 juillet 2026 à 15:27 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

4. 16 juillet 2026 à 15:41 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

5. 16 juillet 2026 à 16:12 UTCresolved

   Orchestrator (UE) est de nouveau disponible depuis 17:32 PM CEST. Toutes les exécutions en cours sont en cours de traitement. Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 10 juillet 2026 à 14:24 UTCinvestigating

   Nous enquêtons actuellement sur un problème qui touche le Centre de traduction de Phrase Strings (régions de l'UE et des États-Unis), où les chaînes ne sont pas chargées. Notre équipe d'ingénieurs a identifié une cause potentielle et travaille activement à la résoudre. Nous fournirons d'autres mises à jour à mesure que notre enquête progressera.

2. 10 juillet 2026 à 14:37 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

3. 10 juillet 2026 à 15:24 UTCresolved

   Cet incident a été résolu.

4. 7 août 2026 à 07:14 UTCpostmortem

   Présentation Le 10 juillet 2026, certaines parties de la façade Phrase Strings à [app.phrase.com](http://app.phrase.com/) n'ont pas été chargées correctement pendant une courte période, après que les feuilles de style et les scripts requis n'ont pas été chargés — le service sous-jacent lui-même est resté disponible. La question a commencé à 16:08 CEST et a été résolue par 16:27 CEST. Ce post mortem explique ce qui s'est passé et ce que nous faisons pour éviter une récidive. Calendrier * **Jul 10, 2026 à 16:08 CEST** – Un déploiement a introduit de nouveaux actifs d'application qui n'ont jamais été téléchargés sur notre service de stockage, de sorte que l'application ne pouvait plus charger ses feuilles de style et scripts pour les clients. * **Jul 10, 2026 à 16:21 CEST** – Délivrance détectée, incident déclaré. * **Jul 10, 2026 à 16:24 CEST** – Cause racine identifiée. * **Jul 10, 2026 à 16:26 CEST** – Correction appliquée. * **Jul 10, 2026 à 16:27 CEST** – Fin de l'impact face au client. * **Jul 10, 2026 à 16:32 CEST** – Incident rétrogradé à la surveillance pendant que la configuration sous-jacente était traitée. * **Jul 10, 2026 à 17:12 CEST** – Configuration corrigée, incident résolu. La cause profonde Lors d'une maintenance planifiée et courante, un changement de configuration a involontairement désactivé le processus qui télécharge les actifs de l'application \(stylesheets, scripts\) vers notre service de stockage et de livraison de contenu. Cela n'a pas été remarqué au début, car les actifs déjà en place fonctionnaient et aucune nouvelle version n'avait encore été expédiée. Le 10 juillet 2026, un déploiement a expédié de nouvelles versions de ces biens. Comme le téléchargement était toujours désactivé, les nouveaux fichiers n'ont jamais atteint le service de stockage, et l'application ne pouvait pas charger ses feuilles de style et ses scripts. Actions pour prévenir la récidive 1. **Réactivation de la synchronisation Le processus désactivé a été corrigé, ce qui a permis de rétablir la bonne livraison des actifs. 2. **Assurer la surveillance de la disponibilité** – Ajouter une surveillance pour détecter automatiquement les défaillances de charge d'actifs, avant que les clients ne soient touchés.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 8 juillet 2026 à 12:57 UTCinvestigating

   Nous recevons des rapports des utilisateurs sur la disparition d'emplois dans les projets et nous enquêtons actuellement sur la question.

2. 8 juillet 2026 à 13:08 UTCmonitoring

   Le problème a été identifié, un correctif a été mis en œuvre et nous suivons la situation.

3. 8 juillet 2026 à 13:55 UTCresolved

   L'incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 7 juillet 2026 à 08:34 UTCinvestigating

   We are currently investigating issues with CAT Web Editor.

2. 7 juillet 2026 à 08:59 UTCmonitoring

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

3. 7 juillet 2026 à 09:27 UTCresolved

   The incident has been resolved.

1. 29 juin 2026 à 07:30 UTCinvestigating

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

2. 29 juin 2026 à 08:05 UTCidentified

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

3. 29 juin 2026 à 08:09 UTCresolved

   This incident has been resolved.

1. 26 juin 2026 à 16:19 UTCinvestigating

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

1. 26 juin 2026 à 07:31 UTCinvestigating

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

2. 26 juin 2026 à 08:16 UTCinvestigating

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