DeepL Outage History

Started Oct 20, 2026, 04:20 PM UTC· resolved Oct 20, 2026, 05:00 PM UTC

1. monitoring Oct 20, 2026, 04:20 PM UTC

   Some customers experienced errors when logging in, making payments, canceling subscriptions, or creating API keys. We have applied a fix, and the issue is now resolved. We continue to monitor the service to ensure it remains stable. We apologize for the disruption.

2. resolved Oct 20, 2026, 05:00 PM UTC

   The issue affecting login, payments, subscription cancellations, and API key creation is resolved. We have identified follow-up actions to help prevent recurrence. We apologize for the disruption.

Read the full incident report →

Started Oct 13, 2026, 09:21 AM UTC· resolved Oct 13, 2026, 09:44 AM UTC

1. monitoring Oct 13, 2026, 09:21 AM UTC

   Part of our Custom rules service is unavailable, affecting users of this service. The service was affected for approx. 8 minutes.

2. resolved Oct 13, 2026, 09:44 AM UTC

   The issue affecting Custom Rules has been resolved, and the service is operating normally.

Read the full incident report →

Started Sep 30, 2026, 12:07 PM UTC· resolved Sep 30, 2026, 01:31 PM UTC

1. investigating Sep 30, 2026, 12:07 PM UTC

   Some users are unable to sign in to DeepL Voice in Microsoft Teams. We’re investigating reports from multiple customers and working to understand the scope of the issue. We’ll provide an update when we have more information.

2. investigating Sep 30, 2026, 12:40 PM UTC

   Some users are unable to sign in with their email address and password through the Microsoft Teams desktop app. We are applying a temporary mitigation and checking whether it restores access. We have not yet confirmed full recovery.If your organization supports single sign-on (SSO), please select Continue with SSO as a workaround. Signing in through browser-based Teams has also worked in our testing.We apologize for the disruption and will share another update as our checks progress.

3. resolved Sep 30, 2026, 01:31 PM UTC

   Users should now be able to sign in to DeepL Voice for Microsoft Teams normally. If you were affected, please try signing in again. We apologize for the disruption.

Read the full incident report →

Started Sep 30, 2026, 11:50 AM UTC· resolved Sep 30, 2026, 11:55 AM UTC

1. investigating Sep 30, 2026, 11:50 AM UTC

   We experienced a brief disruption affecting multiple DeepL products, including Free and Pro translation, document translation, and the DeepL API. During this period, users may have encountered errors or been unable to complete requests. The affected services have recovered, and we are monitoring their stability while investigating the incident. We apologize for the disruption.

2. resolved Sep 30, 2026, 11:55 AM UTC

   The disruption affecting DeepL translation, document translation, the DeepL API, and DeepL Voice has been resolved. We rolled back the change responsible, and the affected services are operating normally again. We apologize for the disruption and thank you for your patience.

Read the full incident report →

Started Sep 29, 2026, 10:00 AM UTC· resolved Sep 29, 2026, 10:00 AM UTC

1. resolved Sep 29, 2026, 10:00 AM UTC

   System montoring shows there was a brief outage with the voice product for 3 minutes in the AsiaPac region. The issue affected 7 calls during the period in question. The problem was caused by a routine roll-out of monitoring services causing an unexpected disruption of already running services. The same roll-out in other regions did not demonstrate this problem. A retrospective into the incident has altready been completed with 2 activites for improvement identified. The first of which has already been complated. The issue ran from 10:02 -10:05 UTC (19:02-19:05 JTC) Our apologies to those customers who were affected by this incident.

Read the full incident report →

Started Sep 18, 2026, 02:30 AM UTC· resolved Sep 18, 2026, 04:37 AM UTC

1. investigating Sep 18, 2026, 02:30 AM UTC

   We are investigating a possible authention problem, leading to sesions expiring and not refreshing correctly. If you experience htis problem, please try logging out from the session and logging in again. Alternatively clear browser cookies, or use try a private (incognito) browser session.

2. investigating Sep 18, 2026, 03:15 AM UTC

   We're investigating the cause of the error messages. Reports indicate this is not affecting the function of the service provided but causing the error message to appear. Clearing the session or the cookies does not resolve the problem, contrary to previous suggestions.

3. investigating Sep 18, 2026, 04:13 AM UTC

   The cause has been identifed with a fix being worked on. The error message is cosmetic and does not affect functionality. A fix is currently being deployed.

4. resolved Sep 18, 2026, 04:37 AM UTC

   A fix for this issue has been deployed. This has been confirmed fixed through tests and corresponding metrics returning to expected levels. Apologies for the inconvienence.

Read the full incident report →

Started Sep 14, 2026, 04:46 AM UTC· resolved Sep 14, 2026, 04:46 AM UTC

1. resolved Sep 14, 2026, 04:46 AM UTC

   On 14 September 2026, between approximately 04:46 and 05:27 UTC, customers using the legacy DeepL Voice integration in Microsoft Teams experienced failures when starting translation and interruptions to translation in ongoing meetings. Service has been restored. We are investigating the underlying cause. We apologize for the disruption.

Read the full incident report →

Started Sep 09, 2026, 03:45 PM UTC· resolved Sep 09, 2026, 04:55 PM UTC

1. identified Sep 09, 2026, 03:45 PM UTC

   We've identified an issue with our Document Translation service leading to a full service outage for the majority of our DocTras customers. We are investigating and will post an update shortly.

2. investigating Sep 09, 2026, 04:15 PM UTC

   We've traced the fault to a routine update in our storage layer. We are investigating possible resolution options and will update shortly.

3. resolved Sep 09, 2026, 04:55 PM UTC

   All systems are now functions correctly and service is fully restored. Apologies for the inconvienence. We will post an RCA document shortly.

4. postmortem Sep 16, 2026, 03:10 PM UTC

   Summary On 9 September 2026, between 16:44 and 17:46 UTC, customers using DeepL Pro document translation from our EU datacenter could not translate documents. Uploads in the web app failed, the document translation API (/v2/document) returned HTTP 500 error code, and an asynchronous translation endpoint used by a CAT-tool integration returned errors. Text translation, the free tier, and customers served from our other data centres were not affected. We are sorry for the disruption. It happened during a planned upgrade of the storage cluster behind these services, and the safeguards we relied on did not prevent it. This was not a security incident: no customer content was accessed, lost, or corrupted. Impact Customers hosted in the EU data centre Document translation, web and API: new document translations could not be started for about one hour. At the peak roughly four in five upload attempts were rejected. Checking on or downloading already-translated documents kept working. Pro API, asynchronous translation endpoint used by a CAT-tool integration: about 1.25 % of all Pro API calls failed in the first 30 minutes, almost all on this endpoint. Data: failed uploads were rejected before completion and never stored. Stored documents were untouched. Affected customers needed to retry their uploads once service was restored. Not affected: text translation and every other API endpoint, the free tier, all other data centres. What happened Document translation stores uploaded documents in an S3-compatible object store, built on the open-source Ceph storage system and operated with the open-source Rook orchestrator. Two kinds of component matter: gateways, which speak S3 to our applications, and storage servers, which hold the data. Larger documents are uploaded in parts and finalised with a "complete" request. Trigger. During the rolling upgrade from Ceph 19.2 to 20.2, the orchestrator upgraded all gateways as soon as the cluster's monitors were on the new version, then began the much longer, server-by-server storage upgrade. For about an hour, new gateways wrote to old storage servers — the reverse of Ceph's documented order. The orchestrator did not enforce that order, and our procedure relied on it. Cause. The new gateway version records a checksum for each uploaded part and requires all checksums to be present when the upload completes. Each part's record is written by the storage server holding it; an old storage server didn't know the new checksum field and silently dropped it. The gateway then found checksums missing and rejected completion with HTTP 400, even though every part had been stored correctly. Whether an upload failed depended only on whether its metadata's server had been upgraded yet — which is why failures disappeared as servers were upgraded. Recovery came from the upgrade progressing past the affected storage servers, not from a mitigation we applied. Alerts fired within three minutes of the first customer-facing error; the status page was updated 21 minutes after impact began, which we want to shorten. Why it was not caught earlier. Our services use the AWS SDK, which requests upload checksums by default. The previous storage version silently ignored them, so this path had never been tested against a server that enforces it. The same upgrade had passed on a smaller pre-production cluster, where the mixed-version window lasted only minutes because that cluster is much smaller, so the mismatch never had time to surface and the upgrade path was confirmed valid for production. Our storage monitoring captured availability and server-side errors, both of which stayed healthy, but the rejections were client-side errors and were not surfaced. Preventative Measures Completed Storage dashboards now show client-facing error rates per bucket and client library. This will bring incident detection for this failure mode within a minute. Both underlying defects are reported to the Ceph and Rook OSS projects maintainers. The Rook community merged a fix that correctly orders storage servers upgrade before gateways. In progress Once a new Rook version is available with the above mentioned fix, upgrade the Rook operator. Meanwhile pause Ceph storage upgrades where possible. Alternatively, if storage upgrades are required, manually keep the gateway version fixed. Add an alert for gateway client-error rates Make the client-side checksum behaviour a configuration setting, so that it’s fully visible application side and be able to modify it without requiring a code change. Planned Treat production storage upgrades as visible change windows, announced in the incident channel in addition to the current announcements to increase internal visibility, and marked on the affected dashboards. Document and test a rollback procedure for the gateway tier before the next version upgrade takes place.

Read the full incident report →

Started Sep 01, 2026, 09:33 PM UTC· resolved Sep 01, 2026, 09:33 PM UTC

1. resolved Sep 01, 2026, 09:33 PM UTC

   This issue has been resolved.

Read the full incident report →

Started Aug 31, 2026, 11:00 AM UTC· resolved Aug 31, 2026, 11:35 AM UTC

1. identified Aug 31, 2026, 11:00 AM UTC

   We're currently experiencing a major disruption. Our team is aware and has started investigating the issue. We’ll provide more details as soon as we have them.

2. resolved Aug 31, 2026, 11:35 AM UTC

   The issue has been resolved and systems are operating normally again. We appreciate your patience and apologize for the interruption. A full review is underway to help prevent this from happening again. A more detailed report on what happened will follow

3. postmortem Aug 31, 2026, 12:01 PM UTC

   During a planned system maintenance we had a dual-failure of another component causing some systems to become unreachable. We will review our redundancy setup for these systems to prevent these failures in the future. We apologize for the disruption.

Read the full incident report →

Started Aug 27, 2026, 02:45 AM UTC· resolved Aug 27, 2026, 09:55 AM UTC

1. investigating Aug 27, 2026, 02:45 AM UTC

   DeepL continues to investigate a problem our central authentication store that is affecting multiple services, including Accounts/Login & voice services.

2. investigating Aug 27, 2026, 04:20 AM UTC

   We continue to see performance issues with our central authentication system which is affecting the usage of a platform across a range of services. A number of successful measures were put in place to help stabalise the system to improve performance but we are still short of normal operating conditions and continue to work on a long term solution.

3. investigating Aug 27, 2026, 06:42 AM UTC

   We've identified the root cause of the sustained higher load and have out in temporary measures to manage the load and restore service to normal levels. We will continue to work on this until we have full restored serviced and resolved the underlying cause.

4. investigating Aug 27, 2026, 07:30 AM UTC

   Service is now largery restored for customers but there are delays in processing license changes. We will continue to work on resolvng the issue.

5. resolved Aug 27, 2026, 09:55 AM UTC

   Service has now been restored and license processing is up to date. We will continue to monitor any issues that arise.

6. postmortem Sep 01, 2026, 08:24 AM UTC

   Root Cause Analysis — Authentication Outage, 26–27 August 2026 Author: Richard Marshall, Head of Site Reliability Date: 28th August 2026 DeepL Incident ID: PIN-805 Summary Between 15:56 UTC on 26 August and ~07:00 UTC on 27 August 2026, sign-in and account operations on DeepL were degraded. A subscription change for a customer triggered a routine license update which, due to an account-linking fault, was applied to a far larger set of accounts than intended. The update couldn't complete, and our systems reprocessed it continuously instead of setting it aside, degrading shared infrastructure the sign-in path depends on. We are treating this as a Severity 1 incident — our highest — and apologise for the disruption. Impact Sign-in error rates exceeded the 5% unavailability threshold, peaking at ~40%; an external monitor recorded our login backend as down. Account info/entitlement retrieval was significantly impaired. Termbases, document translation, voice, and license management were degraded for parts of the window. Because the incident ran overnight in European hours, APAC business hours were most affected, and impact was uneven across services. Timeline (UTC) Time Event 26 Aug 15:56 Subscription change triggers license update against a much larger group than intended; sign-in errors begin 26 Aug 16:08 Incident opened 26 Aug eve–27 Aug early Infrastructure-layer mitigations reduce symptoms but don't resolve the incident 27 Aug ~06:50 License-processing service identified as source of sustained load; processing paused 27 Aug ~07:00 Load normal; service restored 27 Aug ~09:30 Unprocessable request removed, backlog cleared; incident fully mitigated 28 Aug Configuration corrected; incident review held What happened A subscription change for one customer triggered a routine license update. Due to an account-linking issue, the update targeted a much larger account group than intended: instead of a small administrative group, it linked to the customer's default directory-synchronised group. Why it caused an outage The request's size wasn't itself the problem — processed once, it would've been a brief, short-lived demand within normal limits, invisible to customers. The outage happened because the request couldn't complete successfully, and the system reprocessed it repeatedly rather than setting it aside. Each retry repeated the same large demand; the accumulated, sustained load — not a single spike — degraded shared infrastructure and caused sign-in failures. Two design characteristics turned one failed request into a sustained one: the work was issued as one large operation under a single time limit, so it couldn't finish in time; and when it didn't finish, it went back to the front of the queue and retried immediately, with no attempt limit and nowhere else to go. Why it took time to resolve Early symptoms resembled a pattern seen before in our database layer — a reasonable read at the time — so initial remediation focused there, reducing symptoms but not addressing the underlying cause, identified only the next morning. The key fix — pausing license processing — wasn't found until a fresh team took over the next morning and, seeing the growing queue sizes, questioned how the queued messages were interacting with the wider system. Resolution Once license processing was paused, normal service resumed. The unprocessable request was identified, removed, and affected groups were temporarily excluded from automatic license processing to prevent recurrence, letting the backlog clear. The account-linking error has since been corrected and the temporary exclusions removed. A small number of protective database-layer settings applied during the incident remain in place deliberately, pending confirmation of sustained normal performance. What we are doing about it Agreed at the 28 August incident review: Preventing the same trigger Break large license updates into independently processed, queued batches instead of one operation under a single time limit. Already in progress. Remove the account-linking fallback: subscriptions will no longer fall back to a default group; the target group must be specified explicitly. Ensuring a single bad request can't cause an outage Route unprocessable requests to a holding queue after a limited number of attempts instead of retrying indefinitely — isolated for investigation, reprocessed deliberately. Being implemented for the affected service and adopted as a broader messaging-infrastructure standard. Detecting and resolving incidents faster Service run books: DeepL's been rolling these out for call-outs, but this service lacked one. To be corrected, with the owning team defining it in coming weeks.

Read the full incident report →

Started Aug 26, 2026, 02:47 PM UTC· resolved Aug 26, 2026, 03:14 PM UTC

1. investigating Aug 26, 2026, 02:47 PM UTC

   Customers may see a error message "Your User-Agent has been blocked". We are investigating

2. investigating Aug 26, 2026, 03:08 PM UTC

   We found a misconfiguration that caused healthcheck failures and are deploying a fix

3. resolved Aug 26, 2026, 03:14 PM UTC

   The fix was applied successful

Read the full incident report →

Started Aug 26, 2026, 05:55 AM UTC· resolved Aug 26, 2026, 05:55 AM UTC

1. resolved Aug 26, 2026, 05:55 AM UTC

   The incident is resolved

Read the full incident report →

Started Aug 21, 2026, 10:02 PM UTC· resolved Aug 25, 2026, 04:35 PM UTC

1. investigating Aug 21, 2026, 10:02 PM UTC

   We are investigating an issue that may delay availability of some features for newly created accounts, including glossaries and other customizations. Existing services remain available; we are deploying a fix and will provide an update once recovery is confirmed

2. resolved Aug 25, 2026, 04:35 PM UTC

   The issue delaying feature availability for some newly created accounts has been fixed. All queued account setup events have been processed, and services are operating normally.

Read the full incident report →

Started Aug 18, 2026, 10:20 PM UTC· resolved Aug 18, 2026, 10:41 PM UTC

1. investigating Aug 18, 2026, 10:20 PM UTC

   We are investigating elevated error across our servcies. Some users may be getting error messages. We have identified the cause and are working on a fix. A further update will follow shortly.

2. resolved Aug 18, 2026, 10:41 PM UTC

   We found the issue and resolved it. The cause was a routing issue on part of our external load-balancing layer, which stopped directing traffic to the meetings service following a routine deployment. The service itself remained healthy throughout, and customers on internal network connections were not affected. We restored correct routing across all affected load balancers and have confirmed that traffic and error rates are back to normal. We are reviewing the deployment process to prevent a recurrence.

Read the full incident report →

Started Aug 14, 2026, 01:45 PM UTC· resolved Aug 14, 2026, 03:05 PM UTC

1. identified Aug 14, 2026, 01:45 PM UTC

   We are investigating reports of the translator page failing to load affecting DeepL Web for organisations that access DeepL via a custom subdomain. Users may experience a "Something went wrong" error instead of the translator, and may be unable to log in. The issue began around 10:03 UTC. Our team is actively investigating and we will keep you updated as soon as we have more information.

2. investigating Aug 14, 2026, 02:33 PM UTC

   We have carried out a cache purge for DeepL Web to remove outdated JavaScript and HTML files that may have been cached and were preventing the translator page from loading. We are monitoring recovery. Affected users should now be able to load the translator, and may need to refresh the page. We will keep you updated once we have confirmed full recovery.

3. resolved Aug 14, 2026, 03:05 PM UTC

   The issue affecting DeepL Web has been resolved as of 15:04 UTC. Between 10:03 UTC and 15:04 UTC, users at organisations accessing DeepL via a custom subdomain experienced a "Something went wrong" error instead of the translator page, and in some cases were unable to log in. Root cause: outdated JavaScript and HTML files had been cached and were being served to these users, preventing the translator page from loading. These files have been purged from our cache. All services are now operating normally. If you continue to experience issues, please refresh your page, and contact DeepL Support if the problem persists. We apologise for the disruption.

Read the full incident report →

Started Aug 10, 2026, 05:10 PM UTC· resolved Aug 10, 2026, 05:10 PM UTC

1. resolved Aug 10, 2026, 05:10 PM UTC

   Between 17:10 and 17:28 UTC on 10 August 2026, a faulty backend deployment prevented DeepL Voice for Meetings from starting or restoring live-translation sessions. Meetings that were in progress when the issue began may have lost translated captions without an error message and could not restore them by restarting or rejoining — for those meetings, captions remained unavailable until the meeting ended. Meetings started after 17:28 UTC were not affected. Additionally, starting a new 1:1 Conversations session failed for a brief period (17:27:55–17:28:27 UTC); retrying after that time succeeded. This incident is being published retroactively following an internal investigation.

Read the full incident report →

Started Aug 07, 2026, 08:00 AM UTC· resolved Aug 07, 2026, 09:01 AM UTC

1. identified Aug 07, 2026, 08:00 AM UTC

   This morning, we identified a problem causing site failures for customers attempting to use our products. The issue was related to caching of objects following a routine deployment. We have implemented corrective action and are investigating the exact cause and impact of the problem.

2. resolved Aug 07, 2026, 09:01 AM UTC

   We have traced the caused of the issue to a roll back of a prior release, which was performed yesterday. The release was leading to a low level or errors on specific objects, and was therefore reverted. The roll back appears to have left a number of cached objects in our Content Delivery Network which inteferred with the correct operation of our site in customers browsers, which was detected this morning. These objects were cleared from our CDN this morning, which corrected site behaviour. The team are working on improvemnts to our roll-back mechanism which will prevent a similar problem occuring in future.

Read the full incident report →

Started Aug 04, 2026, 04:02 PM UTC· resolved Aug 04, 2026, 05:40 PM UTC

1. investigating Aug 04, 2026, 04:02 PM UTC

   An issue with our license allocation service is preventing newly subscribed customers, and customers on some subscription types from authenticating and gaining access to our system. We are working on a fix for the issue and will deploy this in the next hour.

2. investigating Aug 04, 2026, 05:00 PM UTC

   Engineers are working in deploying a fix for the problem, which is currently affecting approx 1% of customers.

3. investigating Aug 04, 2026, 05:35 PM UTC

   Users signing in to DeepL may be unable to complete login. Users with an active session are generally unaffected. We are deploying on a fix. This is currently affecting approx. 2% of users

4. resolved Aug 04, 2026, 05:40 PM UTC

   The fixes are now fully deployed across production systems and service is restored. We continue to monitor systems.

Read the full incident report →

Started Jul 31, 2026, 09:35 AM UTC· resolved Jul 31, 2026, 12:30 PM UTC

1. investigating Jul 31, 2026, 09:35 AM UTC

   We're aware that some Pro and Enterprise users are currently seeing limited access to their subscription: for example, only administrator options are available, or translation features appear disabled. Existing translations and data are not affected. Our engineering team is actively working to restore full access as quickly as possible. No action is needed on your side.

2. resolved Jul 31, 2026, 12:30 PM UTC

   Earlier today, some Pro and Enterprise users experienced limited access to their subscription. For example, only administrator options were visible, or translation features appeared unavailable. This has now been fixed and normal access has been restored. No data was lost, and existing translations and settings were unaffected throughout. If your account still shows limited access, simply log out and back in to refresh it. Thank you for your patience.

Read the full incident report →

Started Jul 30, 2026, 02:30 AM UTC· resolved Jul 30, 2026, 02:30 AM UTC

1. resolved Jul 30, 2026, 02:30 AM UTC

   On 30.07.2026 between 02:30UTC - 08:30UTC roughly 10% of meetings were in a degraded state. This degraded state manifested in transcription, translation and speech messages arriving very slowly or not at all.

Read the full incident report →

Started Jul 21, 2026, 10:23 AM UTC· resolved Jul 21, 2026, 11:54 AM UTC

1. investigating Jul 21, 2026, 10:23 AM UTC

   We are currently investigating an issue impacting subscription cancellation via our web site. Our engineers are working to restore full functionality as quickly as possible. We’ll provide another update once we have more information.

2. resolved Jul 21, 2026, 11:54 AM UTC

   The issue has been resolved and subscriptions can now be cancelled again through our web site. Thank you for your patience while we worked to restore service.

Read the full incident report →

Started Jul 16, 2026, 05:45 AM UTC· resolved Jul 16, 2026, 09:50 AM UTC

1. investigating Jul 16, 2026, 05:45 AM UTC

   We are currently investigating a increased error rate from Legacy Microsoft Teams bots failing to join meetings. We are currently trying to reproduce the issue. The issue was caused by an underlying problem with the Microsoft Azure infrastructure. We identified and fixed the root cause.

2. resolved Jul 16, 2026, 09:50 AM UTC

   Subsequent investigation of the problems raised this mornign led to the discovery of a problem with the meeting bot. This is now fully resolved.

Read the full incident report →

Started Jul 16, 2026, 05:00 AM UTC· resolved Jul 16, 2026, 06:20 AM UTC

1. investigating Jul 16, 2026, 05:00 AM UTC

   We're currently investigating repots that the agent is unable to join Zoom calls.

2. investigating Jul 16, 2026, 06:00 AM UTC

   We're unable to reproduce the issue and are investigating logs and metrics to determien if an issue occured but is now resolved.

3. resolved Jul 16, 2026, 06:20 AM UTC

   We're marking the incident as resolved - we've been unable to reproduce the problem or find indicators of a problem in our metrics. We will continue to investigate and monitor closely.

Read the full incident report →

Started Jul 07, 2026, 01:08 PM UTC· resolved Jul 07, 2026, 01:08 PM UTC

1. resolved Jul 07, 2026, 01:08 PM UTC

   A rollout at 14:40 CEST has caused a short downtime of Translation Memory features. The change was reverted and functionality is fully restored.

Read the full incident report →