Phrase Outage History

Started Oct 15, 2026, 09:44 AM UTC· resolved Oct 15, 2026, 10:24 AM UTC

1. investigating Oct 15, 2026, 09:44 AM UTC

   We are currently investigating an issue affecting Phrase TMS services in the EU region, including the CAT editor, API, project management, translation memory, and related components. Users may experience errors or be unable to access these services at this time. Our team is actively working to identify the cause and restore full functionality as quickly as possible.

2. monitoring Oct 15, 2026, 09:58 AM UTC

   Services have stabilized and Phrase TMS in the EU region is now operating normally. We keep monitoring the situation.

3. resolved Oct 15, 2026, 10:24 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 23, 2026, 08:48 AM UTC· resolved Sep 23, 2026, 10:03 AM UTC

1. investigating Sep 23, 2026, 08:48 AM UTC

   Some users might be experiencing issues with accessing Phrase TMS.

2. identified Sep 23, 2026, 08:58 AM UTC

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

3. monitoring Sep 23, 2026, 09:28 AM UTC

   The fix has been implemented, and we are monitoring the results. Phrase TMS can now be accessed with no further issues.

4. resolved Sep 23, 2026, 10:03 AM UTC

   This incident has been resolved.

5. postmortem Sep 30, 2026, 12:12 PM UTC

   ## Introduction We would like to share details about an incident that affected access to Phrase TMS on September 23, 2026. Between 9:02 AM and 11:27 AM CEST, users opening Phrase TMS from Phrase Platform could not complete the sign-in. They were either caught in a redirect loop or returned to the Phrase TMS login page with a sign-in error. Users who already had an active Phrase TMS session were not affected, and no customer data was lost or modified. Signing in to Phrase Platform itself kept working throughout the incident, both with a password and with single sign-on. So did signing in with a password directly on the Phrase TMS login page. This post-mortem explains what happened, how it was resolved, and what we are doing to prevent it from happening again. ## Timeline * **Sep 23, 2026 at 9:02 AM CEST** – An update to the Phrase TMS web application went live in production. It included a security improvement to how the sign-in flow handles redirects after login. From this point, users opening Phrase TMS from Phrase Platform could not complete sign-in. Shorty after, the issues was investigated internally. * **Sep 23, 2026 at 10:59 AM CEST** – The update from 9:02 AM CEST was identified as the cause, and we began preparing a rollback. * **Sep 23, 2026 at 11:13 AM CEST** – The rollback was verified in our test environment, and deployment to production started. * **Sep 23, 2026 at 11:27 AM CEST** – The rollback was live in all production regions. Customer-facing impact ended. * **Sep 23, 2026 at 11:28 AM CEST** – We confirmed that signing in to Phrase TMS from Phrase Platform worked again. * **Sep 23, 2026 at 12:04 PM CEST** – The incident was marked as resolved on our status page. ## Root Cause The incident was caused by a security improvement to the Phrase TMS web application. Its goal was to make sure users are only sent to trusted destinations after they sign in. To do this, the web application only accepted redirects to the Phrase TMS web address itself. However, when a user opens Phrase TMS from Phrase Platform, the sign-in process legitimately moves the user between different Phrase web addresses. Our servers already check each of these redirects against a list of trusted Phrase domains and allow them. The new check in the TMS core application was stricter than this server-side check and overrode it. As a result, legitimate redirects were replaced with the Phrase TMS start page, which started the sign-in process again. Users either looped through sign-in repeatedly or landed back on the Phrase TMS login page with an error. Signing in to Phrase Platform itself kept working throughout the incident, both with a password and with single sign-on. So did signing in with a password directly on the Phrase TMS login page. The failure happened at the step where a signed-in user moves from Phrase Platform into Phrase TMS. Because of this, some affected users reported the problem as a password issue: they entered their credentials successfully but were then sent back to a login screen. ## Actions to Prevent Recurrence 1. **Change rolled back** – The update that caused the issue was rolled back in all production regions at 11:27 AM CEST, which restored normal sign-in. 2. **Continuous sign-in monitoring** – We are adding automated checks that run regularly in all production regions and in our test environment. Each check performs the full sign-in from Phrase Platform into Phrase TMS and immediately alerts our on-call engineers if it fails. Before we rely on them, we will confirm that these checks detect the exact failure that occurred in this incident.

Read the full incident report →

Started Sep 10, 2026, 05:06 AM UTC· resolved Sep 10, 2026, 06:03 AM UTC

1. investigating Sep 10, 2026, 05:06 AM UTC

   We are currently investigating an issue affecting the synchronization of jobs between Phrase Strings and Phrase TMS via webhooks in our EU region. Customers may experience failures or delays when syncing translation jobs between the two products. Our team is actively working to identify the root cause and restore full functionality as quickly as possible.

2. monitoring Sep 10, 2026, 05:34 AM UTC

   A fix has been implemented and deployed to address the webhook synchronization failures between Phrase Strings and Phrase TMS. We are currently monitoring the situation to confirm full stability. We will provide a further update once we have validated the resolution.

3. resolved Sep 10, 2026, 06:03 AM UTC

   We are pleased to confirm that the webhook synchronization issue between Phrase Strings and Phrase TMS has been resolved and verified as fully operational, including for US data center customers. This incident is now closed.

Read the full incident report →

Started Sep 01, 2026, 02:18 PM UTC· resolved Sep 01, 2026, 04:23 PM UTC

1. investigating Sep 01, 2026, 02:18 PM UTC

   We are currently investigating an issue causing slowness in the Jobs view within Phrase TMS (EU). Users may experience delayed load times or reduced performance when accessing project management features. Our team is actively working to identify the root cause and restore normal performance as quickly as possible.

2. investigating Sep 01, 2026, 03:00 PM UTC

   We have identified the root cause of the issue. Our team is actively implementing a fix. We will provide further updates as we make progress.

3. monitoring Sep 01, 2026, 03:34 PM UTC

   A fix has been deployed and we are monitoring the results. Customers might need to clear browser cache and close all opened tabs with TMS if still experiencing problems.

4. resolved Sep 01, 2026, 04:23 PM UTC

   The issue has been resolved and performance is stable.

Read the full incident report →

Started Aug 31, 2026, 03:06 PM UTC· resolved Sep 02, 2026, 11:46 AM UTC

1. investigating Aug 31, 2026, 03:06 PM UTC

   We are currently experiencing intermittent errors when communicating with Gengo, one of our third-party translation vendors. This is causing timeouts and 502 errors on price calculation and order submission for translation orders routed through Gengo, affecting both EU and US data centers. Gengo has confirmed the issue on their end and is investigating.

2. resolved Sep 02, 2026, 11:46 AM UTC

   Gengo has resolved the underlying issue on their end. Price calculations and translation order submissions to Gengo is now working.

Read the full incident report →

Started Aug 31, 2026, 01:11 PM UTC· resolved Aug 31, 2026, 04:53 PM UTC

1. investigating Aug 31, 2026, 01:11 PM UTC

   Users are currently unable to open existing jobs and to create new ones within their Phrase TMS projects. We are investigating the issue.

2. investigating Aug 31, 2026, 01:22 PM UTC

   We are continuing to investigate this issue.

3. identified Aug 31, 2026, 01:46 PM UTC

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

4. monitoring Aug 31, 2026, 04:02 PM UTC

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

5. resolved Aug 31, 2026, 04:53 PM UTC

   The issue has been resolved.

6. postmortem Sep 04, 2026, 08:45 AM UTC

   ## Introduction We would like to share details about an incident that affected Phrase TMS on August 31, 2026. Between 2:26 and 5:57 PM CEST, some users of the legacy Project page were unable to use Tools-menu actions such as creating or editing jobs and running analyses, and clicking to open a job did not launch the CAT web editor as expected, instead returning users to the project page. This post-mortem explains what happened, how it was resolved, and what we are doing to prevent it from happening again. ## Timeline * **August 31, 2026 at 2:26 PM CEST** – A code change reached production containing a defect that broke script execution on the Project page for any user who loaded it. * **August 31, 2026 at 2:49 PM CEST** – The first customer reports came in describing Tools-menu buttons as disabled and jobs failing to open in the editor. * **August 31, 2026 at approximately 3:10 PM CEST** – Our team identified the root cause of the issue. * **August 31, 2026 at 3:48 PM CEST** – A fix for the underlying defect was completed. * **August 31, 2026 at 4:04 PM CEST** – The fix was verified in a pre-production environment. * **August 31, 2026 at 5:18 PM CEST** – Deployment of the fix to production began. * **August 31, 2026 at 5:57 PM CEST** – The fix was fully live in production and normal functionality was restored for all affected customers. ## Root Cause The incident was caused by a code change intended to fix an unrelated, minor display issue on shared project pages. That change altered how a value was inserted into a script embedded directly in the page. The system that renders the page automatically encodes values for safety, but that encoding does not distinguish between a value being placed in regular page content versus inside a script. As a result, the embedded script's syntax was silently broken once the change reached production. Because browsers stop executing any further code on a page once they encounter invalid script syntax, every script placed after that point on the page stopped running — not just the part related to the original change. This is why customers experienced what looked like two separate problems \(disabled menu buttons and jobs failing to open in the editor\) that were, in fact, downstream effects of the same single defect. The issue was not caught before release because the verification performed at the time confirmed that the underlying data being inserted was correct, but did not load the actual page in a browser to confirm it rendered and executed correctly end-to-end. ## Actions to Prevent Recurrence 1. **Fix deployed** – The underlying defect was corrected and deployed to production the same day it was identified. 2. **Engineering guidance updated** – We have updated our internal engineering documentation to clearly describe this specific failure pattern and the correct, safe way to handle it, so this category of mistake is caught during code review going forward. 3. **Automated detection improvements underway** – We are working on adding automated monitoring for this class of front-end failure, so similar issues can be detected and addressed before customers are affected, rather than relying on customer reports.

Read the full incident report →

Started Aug 19, 2026, 12:16 PM UTC· resolved Aug 19, 2026, 02:09 PM UTC

1. investigating Aug 19, 2026, 12:16 PM UTC

   We are currently investigating an issue affecting Translation Memory functionality in Phrase TMS (EU). Users may experience problems with creating Translation Memories and other related operations during this time. Our team is actively working to identify the cause and restore full functionality as quickly as possible.

2. identified Aug 19, 2026, 12:34 PM UTC

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

3. monitoring Aug 19, 2026, 01:19 PM UTC

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

4. resolved Aug 19, 2026, 02:09 PM UTC

   The incident has been resolved.

5. postmortem Oct 06, 2026, 08:14 AM UTC

   ## **Introduction** We would like to share more details about the events that occurred with Phrase between 2:11 PM CEST and 4:10 PM CEST on August 19, 2026, which led to degraded Translation Memory functionality in Phrase TMS \(EU\) and what Phrase engineers are doing to prevent these issues from recurring. ## **Timeline** * **August 19, 2026 at 2:11 PM CEST:** Phrase identified an issue affecting Translation Memory functionality in Phrase TMS \(EU\). Users experienced errors when creating translation memories and performing related operations, including confirming segments, elevating error rates across dependant services and use-cases. * **August 19, 2026 at 2:32 PM CEST:** Root cause was identified and engineers began applying a fix to the affected environment by rebalancing the cluster and restarting affected nodes to speed up recovery. * **August 19, 2026 at 3:10 PM CEST:** Translation memory creation and related operations were confirmed to be functioning normally again. * **August 19, 2026 at 4:10 PM CEST:** After a sustained monitoring period showed no recurrence, the incident was marked resolved. ## **Root Cause** Investigation revealed that the incident originated in the database cluster that stores Translation Memory data. A single Translation Memory had, over time, grown very large and required a disproportionate share of read activity to be served by the node that also coordinated the health and metadata management of the wider cluster. Because the cluster was undergoing zero-downtime maintenance spanning days, there was a higher amount of coordination actions and an elevated load on coordination nodes in the cluster. Those two combined with peak load caused multiple coordination nodes performance to slowly deteriorate, leading to elevated error rate and degraded performance. ## **Actions to Prevent Recurrence** To prevent similar incidents in the future and mitigate any negative effects, we: * Rebalanced the cluster and its backing infrastructure to create more headroom for Translation Memory searches and updates. * Paused the ongoing maintenance on impacted Translation Memory cluster. * Improved capacity of coordination node and will be improving cluster’s topology to prevent cluster impact during sudden requests peaks.

Read the full incident report →

Started Aug 07, 2026, 07:27 AM UTC· resolved Aug 07, 2026, 02:12 PM UTC

1. investigating Aug 07, 2026, 07:27 AM UTC

   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. investigating Aug 07, 2026, 07:54 AM UTC

   We are continuing to investigate this issue.

3. identified Aug 07, 2026, 08:18 AM UTC

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

4. monitoring Aug 07, 2026, 08:30 AM UTC

   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. resolved Aug 07, 2026, 02:12 PM UTC

   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.

6. postmortem Sep 11, 2026, 06:11 AM UTC

   ## Introduction We would like to share details about an incident that affected Phrase Strings on the EU platform between August 6 and August 7, 2026. During this period, changes made in branches were not being recorded by our change-processing pipeline. As a result, branches that were merged during the incident could be merged without the changes made to them during that window, and branch comparison screens could show no differences even when differences existed. This post-mortem explains what happened, how it was resolved, and what we are doing to prevent it from happening again. ## Timeline * **August 6, 2026 at 5:44 PM CEST** – A network interruption severed the connection our change-processing pipeline uses to read database changes. The connection failed to recover, and branch changes stopped being processed. The affected component continued to report itself as healthy, so no automated alert was triggered. * **August 7, 2026 at 09:11 AM CEST** – The issue was identified following a customer report. * **August 7, 2026 at 09:19 AM CEST** – The incident was escalated to our highest severity level. * **August 7, 2026 at approximately 10:20 AM CEST** – The affected component was recovered by restarting it, and change processing resumed. * **August 7, 2026 at 10:46 AM CEST** – The backlog of pending changes was fully processed and the pipeline was caught up. * **August 7, 2026 afternoon** – The affected customers were identified and contacted individually with the data needed to restore their changes. ## Root Cause The incident was triggered by a transient network interruption that broke the connection our system uses to stream changes from the database into our branch-processing pipeline. The component responsible for this connection attempted to reconnect automatically, but the reconnection attempt hung indefinitely rather than either succeeding or failing. Because the component never reported a failure, our platform's automatic recovery mechanism — which restarts components that report an error state — was never triggered. The component remained in a state where it appeared to be running normally while processing no changes at all. This is why a standard restart of the connection did not resolve the issue, while fully restarting the underlying process, which established a fresh connection, did. The situation was not detected sooner because our monitoring for this pipeline relied on a signal that continued to report "healthy" throughout the incident, and we did not have a separate measure of whether changes were actually flowing through and being processed. ## Impact * Branches that had changes during the incident but were **not** merged did not lose any data. Their changes were processed once the pipeline recovered. * Branches that **were** merged during the incident were merged without the changes made to them during the incident window. Changes made before the incident were not affected. * Only a small number of customers were ultimately affected. Each was contacted individually and provided with the data and steps needed to restore the affected changes. ## Actions to Prevent Recurrence 1. **Fixed misleading monitoring** – We corrected the monitoring configuration that grouped different production environments together, which had delayed our awareness of the issue. 2. **Adding meaningful health signals** – We are adding monitoring that measures whether changes are actually flowing through the pipeline and how far behind it is, rather than relying on a status signal that can report "healthy" while no work is being done. This ensures a similar stall is detected immediately. 3. **Improving automatic recovery** – We are reviewing the reconnection and retry behaviour of this component so that a stuck connection results in a genuine failure that triggers automatic restart.

Read the full incident report →

Started Aug 06, 2026, 08:11 AM UTC· resolved Aug 06, 2026, 01:19 PM UTC

1. investigating Aug 06, 2026, 08:11 AM UTC

   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. investigating Aug 06, 2026, 08:18 AM UTC

   We are continuing to investigate this issue.

3. monitoring Aug 06, 2026, 08:43 AM UTC

   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. monitoring Aug 06, 2026, 12:00 PM UTC

   We continue monitoring the situation.

5. resolved Aug 06, 2026, 01:19 PM UTC

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

Read the full incident report →

Started Jul 28, 2026, 07:19 AM UTC· resolved Jul 28, 2026, 11:49 AM UTC

1. investigating Jul 28, 2026, 07:19 AM UTC

   Investigating - Engineering has identified an issue with Orchestrator where the new Workflow Engine is currently not executing workflows. The problem is under investigation.

2. investigating Jul 28, 2026, 07:53 AM UTC

   We are continuing to investigate this issue.

3. identified Jul 28, 2026, 08:30 AM UTC

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

4. monitoring Jul 28, 2026, 08:35 AM UTC

   A fix has been implemented and we are monitoring the results. The workflow engine is processing the queue of pending executions.

5. resolved Jul 28, 2026, 11:49 AM UTC

   All executions have been processed. This incident has been resolved.

6. postmortem Jul 30, 2026, 07:09 AM UTC

   ## Introduction We would like to share details about an incident that affected Phrase Orchestrator on July 27–28, 2026. During this period, workflow executions in the Next-Gen Workflow Engine were unable to progress and remained stuck in an "executing" state. No data was lost during the incident. This post-mortem explains what happened, when it was resolved, and the steps we have taken to prevent a recurrence. ## Timeline * **27 July 2026 at 18:55 CEST** – The workflow engine began producing errors as database query performance degraded. Workflow executions stalled and stopped progressing. * **27 July 2026 at 20:54 CEST** – The first customer report of executions stuck in "executing" was received. * **27 July 2026 at 22:39 CEST** – The incident was formally declared. * **28 July 2026 at 02:18 CEST** – A service restart provided temporary relief; workflow executions resumed. * **28 July 2026 at 05:15 CEST** – The issue recurred as the underlying database performance problem persisted. * **28 July 2026 at 09:56 CEST** – The root cause was identified and addressed. No executions were lost; however, due to partial service restarts, some actions within executions were retried, which may have caused a small number of executions to fail that otherwise would have succeeded. * **28 July 2026 at 13:46 CEST** – The full backlog of stalled executions was confirmed as cleared. The system was declared stable. * **28 July 2026 at 13:48 CEST** – Incident resolved. ## Root Cause The incident was caused by progressive bloat in database indexes used by the workflow job scheduling system. The performance of these particular indexes gradually degraded over time as they accumulated dead index entries from prior writes and updates. The job scheduling engine acquires database-level coordination locks while querying these indexes to determine which jobs to dispatch. As the index lookups grew slower, they began exceeding the database's configured statement timeout. When a lookup was canceled by the timeout, the scheduling process responsible for that work crashed and restarted. With no schedulers running, no workflow steps could be dispatched and all in-progress workflow executions became stuck. The database server itself remained healthy throughout the incident, with normal CPU and connection levels. The problem was exclusively lock and latency contention within the scheduling layer. A service restart cleared the crashed processes and temporarily restored execution. However, because the index bloat was still present, the same degradation recurred once query load resumed. A manual index rebuild fully restored performance and resolved the issue. ## Actions to Prevent Recurrence 1. **Automated index maintenance added** – Scheduled automatic index maintenance has been configured for the affected indexes. This ensures bloat cannot accumulate over time and eliminates the conditions that triggered this incident. 2. **Legacy indexes removed** – Unused legacy database indexes have been identified and removed, reducing the overall maintenance surface and simplifying future index hygiene. 3. **Monitoring coverage updated** – Our monitoring landscape is being reviewed and updated to reflect the current state of the workflow engine. This work will close gaps that allowed the degradation to go undetected before the first customer report.

Read the full incident report →

Started Jul 27, 2026, 11:48 PM UTC· resolved Jul 28, 2026, 12:41 AM UTC

1. investigating Jul 27, 2026, 11:48 PM UTC

   Engineering has identified an issue with Orchestrator where the new Workflow Engine is currently not executing workflows. The problem is under investigation.

2. resolved Jul 28, 2026, 12:41 AM UTC

   All workflows are being executed again as expected.

3. postmortem Jul 30, 2026, 07:08 AM UTC

   ## Introduction We would like to share details about an incident that affected Phrase Orchestrator on July 27–28, 2026. During this period, workflow executions in the Next-Gen Workflow Engine were unable to progress and remained stuck in an "executing" state. No data was lost during the incident. This post-mortem explains what happened, when it was resolved, and the steps we have taken to prevent a recurrence. ## Timeline * **27 July 2026 at 18:55 CEST** – The workflow engine began producing errors as database query performance degraded. Workflow executions stalled and stopped progressing. * **27 July 2026 at 20:54 CEST** – The first customer report of executions stuck in "executing" was received. * **27 July 2026 at 22:39 CEST** – The incident was formally declared. * **28 July 2026 at 02:18 CEST** – A service restart provided temporary relief; workflow executions resumed. * **28 July 2026 at 05:15 CEST** – The issue recurred as the underlying database performance problem persisted. * **28 July 2026 at 09:56 CEST** – The root cause was identified and addressed. No executions were lost; however, due to partial service restarts, some actions within executions were retried, which may have caused a small number of executions to fail that otherwise would have succeeded. * **28 July 2026 at 13:46 CEST** – The full backlog of stalled executions was confirmed as cleared. The system was declared stable. * **28 July 2026 at 13:48 CEST** – Incident resolved. ## Root Cause The incident was caused by progressive bloat in database indexes used by the workflow job scheduling system. The performance of these particular indexes gradually degraded over time as they accumulated dead index entries from prior writes and updates. The job scheduling engine acquires database-level coordination locks while querying these indexes to determine which jobs to dispatch. As the index lookups grew slower, they began exceeding the database's configured statement timeout. When a lookup was canceled by the timeout, the scheduling process responsible for that work crashed and restarted. With no schedulers running, no workflow steps could be dispatched and all in-progress workflow executions became stuck. The database server itself remained healthy throughout the incident, with normal CPU and connection levels. The problem was exclusively lock and latency contention within the scheduling layer. A service restart cleared the crashed processes and temporarily restored execution. However, because the index bloat was still present, the same degradation recurred once query load resumed. A manual index rebuild fully restored performance and resolved the issue. ## Actions to Prevent Recurrence 1. **Automated index maintenance added** – Scheduled automatic index maintenance has been configured for the affected indexes. This ensures bloat cannot accumulate over time and eliminates the conditions that triggered this incident. 2. **Legacy indexes removed** – Unused legacy database indexes have been identified and removed, reducing the overall maintenance surface and simplifying future index hygiene. 3. **Monitoring coverage updated** – Our monitoring landscape is being reviewed and updated to reflect the current state of the workflow engine. This work will close gaps that allowed the degradation to go undetected before the first customer report.

Read the full incident report →

Started Jul 20, 2026, 11:00 AM UTC· resolved Jul 21, 2026, 08:53 AM UTC

1. resolved Jul 20, 2026, 12:53 PM UTC

   Between June 16, 2026 01:00PM CEST and June 17, 2026 11:00AM CEST, the Phrase Job Sync connector suffered degraded performance. Customers using the Job Sync with the default connection type experienced failures. The engineering team identified a root cause and provided a fix.

2. postmortem Jul 20, 2026, 12:54 PM UTC

   ### Introduction We would like to share more details about the events that occurred with Phrase between June 16, 2026, 01:00PM CEST and June 17, 2026, 11:00AM CEST, which led to degraded performance of Phrase Strings API, causing customers using the Job Sync with the default connection type to experience failures. We apologize for the disruption and are committed to preventing similar incidents in the future. ### Timeline **Jun 16, 2026 @ 01:00 PM CEST** – Job Sync began failing for customers using the default connection type. Connectors were unable to authenticate against the Phrase Strings API. **Jun 17, 2026 @ 10:00 AM CEST** – The authentication failure was identified by the engineering team. **Jun 17, 2026 @ 10:28 AM CEST** – Impact scope was confirmed: Customers using the default Job Sync connection were affected. Customers using personal access token-based connectors were not affected. **Jun 17, 2026 @ 10:29 AM CEST** – Root cause was identified: A recent change which added multi-platform token support inadvertently introduced errors with some existing platform tokens. **Jun 17, 2026 @ 10:40 AM CEST** – A fix was prepared and submitted for review. **Jun 17, 2026 @ 10:53 AM CEST** – The fix was deployed and JobSync functionality was fully restored. ### Root Cause A code change introduced to add support for multi-platform authentication tokens modified how incoming platform tokens are validated and processed in the Phrase Strings API. This change was not compatible with an existing token format used by the default connection type. As a result, platform tokens were rejected by the Strings API with a `401 Unauthorized` response. The connector retried establishing the connection until exhausting its retry budget, causing all affected operations to fail. Customers using personal access tokens were not affected as their tokens follow a different code path. ### Actions to Prevent Recurrence The root cause was a backwards-incompatible change to token handling that was not detected during development. The following actions are being taken: * **Token format compatibility testing in auth changes:** When introducing a new token/authentication format alongside an existing one, tests must explicitly cover the transition case—old-format tokens being processed under the new detection logic—not just each format in isolation.

Read the full incident report →

Started Jul 16, 2026, 03:47 PM UTC· resolved Jul 20, 2026, 12:07 PM UTC

1. investigating Jul 16, 2026, 03:47 PM UTC

   We are currently investigating an issue affecting our Metrics service that may result in duplicated metrics consumption for some customers. Our team is actively working to identify the affected components and determine the root cause. We will provide further updates as more information becomes available.

2. identified Jul 16, 2026, 04:29 PM UTC

   We have identified the root cause as instability on a specific broker, which is causing repeated consumer group rebalancing in our Metrics service and leading to duplicate processing of metric updates. This may result in some customers experiencing incorrect consumption calculations or unexpected account blocking. We continue working on a fix.

3. monitoring Jul 16, 2026, 05:31 PM UTC

   We have stopped the progression of the issue and are now working to identify the full scope of impact, including which organizations are affected or blocked. Affected accounts will be prioritized for resolution through a deduplication process, though this will take some time to complete.

4. identified Jul 16, 2026, 07:04 PM UTC

   We have successfully deduplicated metrics consumption for all blocked organizations. We are continuing work to develop per-organization deduplication tooling to ensure accurate billing cycle data, with the full team scaling these fixes tomorrow morning.

5. monitoring Jul 17, 2026, 01:02 PM UTC

   We continue to make progress resolving the duplicated metrics consumption issue first identified on July 16. The root cause has been identified and addressed. Since our last update, our team has corrected the duplicated data for all previously blocked accounts. We are now working through a remaining set of affected accounts and expect this cleanup to continue over the coming days. No further duplication is occurring, this work addresses historical data only.

6. resolved Jul 20, 2026, 12:07 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 16, 2026, 02:49 PM UTC· resolved Jul 16, 2026, 04:12 PM UTC

1. investigating Jul 16, 2026, 02:49 PM UTC

   We are currently investigating an issue affecting Phrase Orchestrator. We are working to identify the root cause and will provide further updates as soon as more information is available.

2. investigating Jul 16, 2026, 03:27 PM UTC

   We are continuing to investigate this issue.

3. identified Jul 16, 2026, 03:27 PM UTC

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

4. monitoring Jul 16, 2026, 03:41 PM UTC

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

5. resolved Jul 16, 2026, 04:12 PM UTC

   Orchestrator (EU) is available again since 5:32 PM CEST. All pending executions are being processed. This incident has been resolved.

Read the full incident report →

Started Jul 10, 2026, 02:24 PM UTC· resolved Jul 10, 2026, 03:24 PM UTC

1. investigating Jul 10, 2026, 02:24 PM UTC

   We are currently investigating an issue affecting the Translation Center in Phrase Strings (EU and US regions), where strings are failing to load. Our engineering team has identified a potential cause and is actively working to resolve it. We will provide further updates as our investigation progresses.

2. monitoring Jul 10, 2026, 02:37 PM UTC

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

3. resolved Jul 10, 2026, 03:24 PM UTC

   This incident has been resolved.

4. postmortem Aug 07, 2026, 07:14 AM UTC

   ## 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.

Read the full incident report →

Started Jul 08, 2026, 12:57 PM UTC· resolved Jul 08, 2026, 01:55 PM UTC

1. investigating Jul 08, 2026, 12:57 PM UTC

   We are getting reports from users about jobs disappearing from projects and we are currently investigating the issue.

2. monitoring Jul 08, 2026, 01:08 PM UTC

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

3. resolved Jul 08, 2026, 01:55 PM UTC

   The incident has been resolved.

Read the full incident report →

Started Jul 07, 2026, 08:34 AM UTC· resolved Jul 07, 2026, 09:27 AM UTC

1. investigating Jul 07, 2026, 08:34 AM UTC

   We are currently investigating issues with CAT Web Editor.

2. monitoring Jul 07, 2026, 08:59 AM UTC

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

3. resolved Jul 07, 2026, 09:27 AM UTC

   The incident has been resolved.

Read the full incident report →

Started Jun 29, 2026, 07:30 AM UTC· resolved Jun 29, 2026, 08:09 AM UTC

1. investigating Jun 29, 2026, 07:30 AM UTC

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

2. identified Jun 29, 2026, 08:05 AM UTC

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

3. resolved Jun 29, 2026, 08:09 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 26, 2026, 07:31 AM UTC· resolved Jun 26, 2026, 08:28 AM UTC

1. investigating Jun 26, 2026, 07:31 AM UTC

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

2. investigating Jun 26, 2026, 08:16 AM UTC

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

Read the full incident report →

Started Jun 22, 2026, 11:20 AM UTC· resolved Jun 22, 2026, 01:07 PM UTC

1. investigating Jun 22, 2026, 11:20 AM UTC

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

2. investigating Jun 22, 2026, 11:57 AM UTC

   We are continuing to investigate this issue.

3. identified Jun 22, 2026, 12:40 PM UTC

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

4. monitoring Jun 22, 2026, 12:50 PM UTC

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

5. monitoring Jun 22, 2026, 01:06 PM UTC

   We are continuing to monitor for any further issues.

6. resolved Jun 22, 2026, 01:07 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 03, 2026, 03:01 PM UTC· resolved Jun 03, 2026, 03:48 PM UTC

1. investigating Jun 03, 2026, 03:01 PM UTC

   We are currently investigating this issue.

2. resolved Jun 03, 2026, 03:48 PM UTC

   This incident has been resolved.

3. postmortem Jun 15, 2026, 01:43 PM UTC

   ### Introduction We would like to share more details about a service disruption that affected Phrase TMS on June 3, 2026. Between 16:39 and 17:02 CEST, customers experienced errors and degraded performance when accessing Phrase TMS in both the EU and US regions. The engineering team identified and resolved the issue within approximately 23 minutes. We apologize for the disruption and are committed to preventing similar incidents in the future. ## Timeline **Jun 3, 2026 @ 16:39 CEST** – Phrase TMS began returning errors for customers in both EU and US regions. Our monitoring/alerting detected this and on-call engineers were alerted and began investigation immediately. **Jun 3, 2026 @ 16:42 CEST** – The root cause was identified as a backwards-incompatible database schema change applied during a recent deployment. A status page update was posted to inform customers that the team was investigating. **Jun 3, 2026 @ 16:53 CEST** – A remediation was prepared to revert the incompatible schema change directly in the database. **Jun 3, 2026 @ 17:00 CEST** – The schema change was successfully reverted in the EU region. Phrase TMS in the EU region recovered and began serving requests normally. **Jun 3, 2026 @ 17:02 CEST** – The same remediation was applied in the US region. Full service was restored across both regions. **Jun 3, 2026 @ 17:48 CEST** – The status page incident was marked as resolved after continued monitoring confirmed stable operation. ## Root Cause During a planned deployment, a database schema change was applied that renamed a column in an internal database table. This change was not backwards-compatible with the version of the application currently running in production. Our production deployment process vs the QA one applies database schema changes separately before rolling out updated application instances — a standard and normally safe approach for additive changes. However, a column rename immediately invalidates queries from the currently running application that reference the original column name. As this did not cause any issues in QA the problem was not immediately caught. As a result, during the window between the schema change being applied and the new application version completing its rollout, all running application instances executed database queries referencing a column that no longer existed, causing all affected requests to fail with errors. ## Actions to Prevent Recurrence The root cause was a backwards-incompatible schema change applied in a single step during a rolling deployment. The following actions have been taken to prevent a recurrence: * **Code review guidelines updated:** Engineering review guidelines now require reviewers to raise a blocking finding for any database schema migration that is not backwards-compatible with the previously deployed application version. This explicitly covers column renames, column drops, table renames, and constraint additions that would cause running application instances to fail. * **Safe schema change pattern enforced:** The engineering team is required to use an incremental, multi-step approach for destructive schema changes: the new structure is added alongside the existing one in a first deployment, the application transitions across subsequent deployments, and the old structure is removed only once no running application instance references it.

Read the full incident report →

Started May 27, 2026, 08:19 PM UTC· resolved Jun 02, 2026, 09:20 AM UTC

1. investigating May 27, 2026, 08:19 PM UTC

   We are currently investigating delays in some tasks like job creation, QA and analysis.

2. investigating May 27, 2026, 09:30 PM UTC

   We are continuing to investigate this issue.

3. monitoring May 27, 2026, 11:51 PM UTC

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

4. resolved Jun 02, 2026, 09:20 AM UTC

   This incident has been resolved.

Read the full incident report →

Started May 21, 2026, 09:42 AM UTC· resolved Jun 10, 2026, 01:01 PM UTC

1. investigating May 21, 2026, 09:42 AM UTC

   We are investigating an issue affecting Phrase Analytics (TMS) and Phrase Data since May 4, 2026. Customers may see missing or incorrect analytics metrics for some jobs. Specifically: Processed words may be missing for jobs with Chinese, Japanese, or Korean (CJK) as the source language. Characters, completed words, confirmed words, and locked words may be missing for jobs across all language combinations. We are continuing to investigate and will share further updates as soon as possible.

2. investigating May 21, 2026, 01:10 PM UTC

   We are continuing to investigate this issue.

3. monitoring May 22, 2026, 11:08 AM UTC

   We have identified and fixed the root cause. Analytics data should be flowing again for most projects starting today (22 May). We are working on re-ingesting the missing data for the period of 4–21 May, and will share progress updates until that's complete.

4. resolved Jun 10, 2026, 01:01 PM UTC

   This incident has been resolved.

5. postmortem Jun 11, 2026, 07:21 PM UTC

   ### Introduction We would like to share details about an incident that affected **Phrase Analytics** and Phrase Data between May 4, 2026 and Jun 1, 2026. During this period, segment-based analytics metrics - including character and word counts \(completed, confirmed and locked\), words processed with CJK source language - displayed as zero for data created or updated within the affected window. This post-mortem outlines what happened, when it was resolved, and the steps we are taking to prevent a recurrence. ### Timeline May 4, 2026 - A configuration change to our analytics data ingestion pipeline unintentionally caused it to re-process all historical data rather than only new changes. This placed significant additional load on our message streaming infrastructure, where current changes were competing with past changes and serialised at the end of processing queue. May 7, 2026 - The increased load led to storage pressure within the streaming cluster, causing analytics processing to slow down. May 14, 2026 - We were continuously fixing capacity and work assignments in the streaming cluster to mitigate increased load and allow lag processing. May 21, 2026 at 1:30 PM CEST - We identified the root cause why the lag is not being processed in timely manner and took corrective action: the ingestion pipeline was stopped and restarted in the incremental mode, and additional streaming infrastructure capacity was provisioned. May 22, 2026 at 4:00 AM CEST - New segment data began flowing correctly into the analytics system. May 22, 2026 - A secondary defect was identified and fixed: the pipeline incorrectly handled a specific sequence of segment deletion events within the replay window, which could cause a small number of records to be missed. May 26, 2026 at 10:20 AM CEST - Customer-facing impact ended. Analytics was processing new data correctly and all current-period data was visible. May 27, 2026-Jun 1, 2026 - Historical data from May 4, 2026–May 21, 2026 was backfilled across all processing nodes. When verifying we noticed missing data still for some segments on May 10, 2026, May 14, 2026 and May 15, 2026. Jun 1, 2026-Jun 9, 2026 - With revised and fixed data pipeline we re-run data to backfill missing data. Jun 9, 2026 - Validated and confirmed all data were backfilled. ### Root Cause The incident was caused by a configuration change on May 4, 2026 that accidentally triggered a full re-synchronization of all historical analytics data instead of the intended incremental update. The resulting data volume significantly exceeded the capacity of our message streaming infrastructure. As the system fell behind processing the backlog, analytics statistics stopped being written, causing zeros to appear in customer-facing reports. ### Actions to Prevent Recurrence 1. **Data backfilled and verified** - Historical analytics data for the May 4, 2026–May 21, 2026 window has been restored across all processing nodes and verified against source systems. 2. **Streaming infrastructure scaled** - Capacity of the message streaming cluster has been increased to provide headroom for high-load scenarios and prevent disk pressure from recurring. 3. **Pipeline defects fixed** - A secondary bug affecting a small number of deleted segments in the replay window has been resolved. 4. **Performance improvement underway** - A fix is in progress to dramatically reduce processing time for jobs with unusually large segment volumes, reducing the risk of future processing delays. 5. **Analytics data freshness monitoring** - We are adding internal alerting so that any future delays in the analytics pipeline are detected and acted on before customers are impacted.

Read the full incident report →

Started May 13, 2026, 01:49 PM UTC· resolved May 13, 2026, 01:49 PM UTC

1. resolved May 13, 2026, 01:49 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 07, 2026, 04:00 PM UTC· resolved May 07, 2026, 04:00 PM UTC

1. resolved May 19, 2026, 02:59 PM UTC

   We identified an issue that caused delayed data processing in Strings Analytics. As a result, some customers may have seen stale or delayed analytics data. A fix has been implemented and reprocessing has been started, but some affected tables are large, so backlog processing is still catching up. Customers may continue to see delayed or stale data until processing is fully completed.

Read the full incident report →