76 Phraseapp incidents · 2024年8月 — official updates, affected components, duration and resolution details.
我们目前正在调查一个影响欧盟地区语言TMS服务的问题,包括CAT编辑器、API、项目管理、翻译记忆和相关组件。 用户此时可能遇到错误或无法访问这些服务. 我们的团队正在积极开展工作,以查明原因并尽快恢复全部功能.
服务已经稳定下来,欧盟地区的词汇TMS现在正常运行。 我们继续监视局势.
这一事件已经得到解决.
自动翻译自官方事件更新。
一些用户在访问用词TMS时可能会遇到问题.
这一问题已经确定,一个解决办法正在实施之中.
解决办法已经落实,我们正在监测结果。 词语TMS现在可以访问,不再发行.
这一事件已经得到解决.
□ 导言 我们想详细介绍2026年9月23日发生的一起影响入读"语言TMS"的事件. 在9:02 AM到11:27 AM CEST之间,用户从Phase平台打开了Phase TMS无法完成登录. 它们要么被夹入了重定向回路圈,要么返回到有登录错误的Phase TMS登录页面. 已经有过活跃的词组TMS会话的用户没有受到影响,也没有丢失或修改客户数据. 签入词平台本身在整个事件中始终保持工作状态,既有密码,也有单签. 直接在Phase TMS登录页面上用密码签名也一样. 这一死后事件解释了发生的事情,它是如何解决的,以及我们正在采取什么行动防止它再次发生. □ 时间线 * 第23行,第2026行,上午9:02 AM CEST** — Phase TMS网络应用程序的更新在制作中投入使用. 其中包括对登录后的登录流程处理进行安全改进。 从此,用户从Phase Platface 打开词组TMS无法完成登录. 短后,问题被内部调查. * 第23行,第2026行,第10:59分 9:02 AM CEST的更新被确定为原因,我们开始准备回滚. * 第23、2026页,11:13 AM CEST** - 在我们的试验环境中对回滚进行了核实,并开始投入生产。 * 第23、2026页,11:27 AM CEST** - 反弹在所有生产地区都进行了现场直播。 顾客的冲击结束。 * Sep 23, 2026 at 11:28 AM CEST** – 我们确认,从用词平台签入用词TMS再次奏效. * 第23行,第2026页 PM CEST ** — 在我们的状态页面上,这一事件被标为已解决。 □ 根源 事件由Phase TMS网络应用程序的安全改进所引起. 它的目标是确保用户只有在注册后才能被送到信任的目的地. 要做到这一点,网络应用程序只接受重定向到词组TMS网络地址本身. 然而,当用户从词组平台打开词组TMS时,登录程序会合法地将用户移动到不同的词组网络地址之间. 我们的服务器已经对照一个信任的词组域列表, 检查每个这些方向并允许它们 。 TMS核心应用程序中的新检查比服务器侧检查更为严格并被推翻. 因此,合法的重定向被替换为Phrase TMS起始页面,这又开始了登录进程. 用户要么反复地通过签入循环,要么以出错的方式登陆到Phase TMS登录页面上. 签入词平台本身在整个事件中始终保持工作状态,既有密码,也有单签. 直接在Phase TMS登录页面上用密码签名也一样. 失败发生在一个签入的用户从用词平台移动到用词TMS的阶段. 由于这个原因,一些受到影响的用户将这个问题报告为密码问题:他们成功输入了证书,但随后被送回登录屏幕. □ 防止再起的行动 1. ** 转回** - 导致发行的更新在11:27AM CEST在所有生产区回滚,恢复了正常的签入. 2.** 持续的登录监测** -- -- 我们正在增加所有生产区域和试验环境中的自动检查。 每次检查都完成从用词平台到用词TMS的全签名,如果失败,立即通知我们的待命工程师. 在我们依靠它们之前,我们将确认这些检查发现了这次事件中发生的确切失败.
自动翻译自官方事件更新。
我们目前正在调查一个影响我们欧盟区域通过网络呼声使词串和词串TMS之间工作同步的问题。 客户在同步两种产品之间的翻译工作时可能会遇到故障或延误. 我们的团队正在积极努力,找出根源,并尽快恢复全部功能.
已执行并部署一个固定,以解决Phase Strings和Phase TMS之间的webhook同步故障. 我们目前正在监测局势,以确认完全稳定。 一旦决议得到确认,我们将提供进一步的最新情况.
我们高兴地确认,措辞字符串和措辞TMS之间的Webhook同步问题已经得到解决,并被核实为充分运作,包括针对美国数据中心客户。 这一事件现已了结.
自动翻译自官方事件更新。
目前,我们正在调查一个引起欧盟语言管理系统中乔布斯观点缓慢的问题。 用户在访问项目管理功能时可能遭遇延迟载荷时间或性能下降. 我们的团队正积极努力,找出根源,并尽快恢复正常表现.
我们确定了这一问题的根源。 我们的团队正在积极执行一个解决方案。 随着我们的进展,我们将提供进一步的最新情况.
已经部署了一个固定方案,我们正在监测结果。 客户可能需要清除浏览器缓存并关闭所有打开的带有TMS的标签,如果仍然遇到问题的话.
问题已经解决,工作情况稳定.
自动翻译自官方事件更新。
我们目前正在与我们的第三方翻译供应商之一Gengo进行联系时出现间歇性错误。 这导致通过Gengo发送的翻译订单在价格计算和订单上出现超时和502个错误,影响到欧盟和美国的数据中心。 根戈在最后证实了这个问题,并正在进行调查.
根戈已经解决了问题 价格计算和向Gengo提交的翻译订单现已恢复工作.
自动翻译自官方事件更新。
用户目前无法打开现有工作,也无法在其语言TMS项目中创建新的工作。 我们正在调查这个问题.
我们正在继续调查这一问题.
这一问题已经确定,一个解决办法正在实施之中.
一项措施已经执行,我们正在监测结果.
这个问题已经得到解决.
□ 导言 我们想谈谈2026年8月31日一起影响文字TMS事件的细节. 在2:26至5:57 PM CEST之间,遗留项目页面的一些用户无法使用工具菜单动作,如创建或编辑工作并运行分析,而点击打开一个工作并没有如预期的那样启动CAT网络编辑器,而是将用户返回项目页面. 这一死后事件解释了发生的事情,它是如何解决的,以及我们正在采取什么行动防止它再次发生. □ 时间线 * ** 2026年8月31日2:26 PM CEST** – 一个代码更改达到了生产,其中包含一个缺陷,使任何加载该代码的用户在项目页面上出现脚本执行中断. * 2026年8月31日 2:49 PM CEST** — 最早的客户报告是在描述"工具菜单"按钮为已禁用并未能在编辑器中打开的工作. * 2026年8月31日,大约3:10 PM CEST** – 我们的团队确定了问题的根源. * 2026年8月31日3:48 PM CEST** – 基本缺陷的修补完成. * 2026年8月31日,下午4时04分 在生产前的环境下对固定装置进行了核查。 * 2026年8月31日5:18 PM CEST** — 开始部署生产固定装置。 * 2026年8月31日,下午5时57分 固定装置已完全投入生产,所有受影响的客户都恢复了正常功能。 □ 根源 事件由代码更改所引起,意在解决共享项目页面上一个无关的小显示问题. 这一变化改变了将一个值插入直接嵌入页面的脚本的方式。 使页面自动编码安全值的系统,但该编码并不区分放置在正版页面内容中的值与脚本内部的值. 因此,嵌入式脚本的语法在变化达到出产后被无声地打破. 因为浏览器一旦遇到无效的脚本语法,就停止执行页面上任何进一步的代码,所以页面上该分后放入的每个脚本都停止了运行——而不仅仅是与原更改相关的部分. 这就是为什么顾客经历了两个不同的问题\(在编辑器中无法打开的菜单按钮和工作),事实上,这两个问题都是同一个缺陷造成的下游影响。 这个问题在发布前没有被抓住,因为当时进行的核实确认被插入的基本数据是正确的,但并没有将实际的页面加载到浏览器中以确认其提供并正确执行端到端. □ 防止再起的行动 1. ** 已部署部队** - 基本缺陷得到纠正,并在查明缺陷的同一天投入生产。 2. ** 更新工程指导** - 我们更新了内部工程文件 以清楚地描述这个具体的故障模式 以及正确,安全的方法 处理它,所以这一类错误 是在代码审查 前进。 3. ** 自动化探测改进正在进行** - 我们正在努力为这一类前端故障增加自动监测,因此在客户受到影响之前可以发现并解决类似问题,而不是依赖客户报告.
自动翻译自官方事件更新。
我们目前正在调查一个影响语言TMS(欧盟)翻译记忆功能的问题。 在此期间,用户在创建"翻译记忆"和其他相关操作时可能会遇到问题. 我们的团队正在积极开展工作,以查明原因并尽快恢复全部功能.
这一问题已经确定,一个解决办法正在实施之中.
一项措施已经执行,我们正在监测局势.
此事已决.
□ ** 导言** 2026年8月19日2:11 PM CEST至4:10 PM CEST之间, □** 时间线** * 2026年8月19日,下午2时11分 词组识别出一个影响词组 TMS\(EU\)中翻译内存功能的问题. 用户在创建翻译记忆和开展相关业务时遇到错误,包括确认部分、提高依赖性服务和使用案件的错误率。 * 2026年8月19日,下午2:32 查明了根源,工程师开始对受影响环境采用固定办法,重新平衡集群并重新启动受影响的节点来加快恢复。 * 2026年8月19日,下午3时10分 翻译记忆的创建和相关操作被证实再次正常运行. * 2026年8月19日,下午4时10分 在持续监测期间显示没有再次发生后,这一事件得到了解决。 □** 轮回原因** 调查显示,事件起源于存储"翻译记忆"数据的数据库集群. 随着时间的推移,一个单一的翻译记忆已经变得非常庞大,需要一个节点为阅读活动提供不成比例的份额,该节点还负责协调更广泛的集群的健康和元数据管理。 由于该组正在经历持续数天的零下行时间维护,因此该组的协调行动量较高,协调节点负荷也较高。 两者加之高峰负载,导致多个协调节点性能缓慢恶化,导致出错率高和性能退化. □ ** 防止再起的行动** 为了防止今后发生类似事件并减轻任何不利影响,我们: * 重新平衡集群及其支持基础设施,为翻译内存搜索和更新创建更多的主室。 * 暂停对已受影响的翻译记忆组的持续维护。 * 提高协调节点的能力并正在改进集群的地貌,以防止在突然提出要求高峰时对集群产生影响.
自动翻译自官方事件更新。
我们目前正在调查一个在用词字符串(欧盟)中缺少分支事件的问题,这可能导致在分支合并时不适用更改.
我们正在继续调查这一问题.
这一问题已经确定,一个解决办法正在实施之中.
已经执行了一项固定措施。 目前正在处理积压的失踪事件。 队列完成后,未合并的分支会自动接收缺失的更改. 我们正在监测排队情况和结果.
事故窗口期间对分支机构所作的改动现已充分应用。 已经查明了受影响的被合并的分行,并直接与受影响的客户联系。 这一事件已经得到解决.
□ 导言 我们想谈谈2026年8月6日至8月7日在欧盟平台上发生的一起影响用词字符串的事件的细节。 在此期间,我们的变更处理管道没有记录分支的变更。 因此,在事发期间合并的分会可以合并而无需在该窗口内对分会作出更改,分会比较屏幕即使存在差异,也不会显示任何差异. 这一死后事件解释了发生的事情,它是如何解决的,以及我们正在采取什么行动防止它再次发生. □ 时间线 * 2026年8月6日5:44 PM CEST** – 一个网络中断断开我们更改处理管道用来读取数据库变化的连接. 连接无法恢复, 分支更改停止处理 。 受影响的部分继续报告自己健康,因此没有启动自动警报。 * 2026年8月7日09时11分 这一问题是在客户报告之后确定的。 * 2026年8月7日09:19 AM CEST** — 事件升级到我们的最高程度 * 2026年8月7日10时20分左右 通过重新启动恢复了受影响的部分,并恢复了变更处理。 * 2026年8月7日10时46分 积压的待决变动已全部处理完毕,编审工作陷入困境。 * 2026年8月7日下午** - 确定了受影响的客户,并与他们个别联系,了解恢复其变化所需的数据。 □ 根源 事件是由一个瞬间网络中断引发的,中断了我们系统用来从数据库中流到分支处理管道的连接. 负责这一连接的组件试图自动重联,但重联尝试无限期地挂起,而不是成功或失败. 由于组件从未报告故障,我们平台的自动恢复机制——它重新启动了报告出错状态的组件——从未被触发. 该组件仍然处于正常运行的状态,但没有任何变化。 正因为如此,标准的连接重启未能解决问题,同时完全重启了建立新连接的基础进程,但最终得以实现. 由于我们对这一管道的监测依赖于在整个事件中继续报告"健康"的信号,而且我们没有单独衡量变化是否确实在流出和正在处理之中,所以这种情况没有早被发现. □ 影响 * 事件中有变化但**没有**合并的分支机构没有丢失任何数据。 一旦管道恢复,就对其进行了修改。 * 事件期间合并** 的分会合并,但没有在事件窗口期间作出更改。 事发前的变动没有受到影响. * 只有少数客户最终受到影响。 已分别与各自联系,并提供了恢复受影响变化所需的数据和步骤。 □ 防止再起的行动 1. ** 误导性监测** -- -- 我们纠正了将不同的生产环境组合在一起的监测配置,这延误了我们对问题的认识。 2. ** 添加有意义的健康信号** - 我们正在增加监测,以衡量变化是否实际上正在通过管道流出,其背后还有多远,而不是依赖一个能够报告“健康”状况的信号,而目前还没有开展工作。 这样可以确保立即发现类似的摊位。 3. ** 改进自动追回** - 我们正在审查这一组件的再连接和再试验行为,以便一个被卡住的连接导致真正的失败,从而触发自动重启.
自动翻译自官方事件更新。
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.
We are continuing to investigate this issue.
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.
We continue monitoring the situation.
The incident has been resolved and all components are back to operational.
工程小组与Orchestrator发现一个问题,即新的工作流程引擎目前没有执行工作流程。 问题正在调查中.
我们正在继续调查这一问题.
这一问题已经确定,一个解决办法正在实施之中.
一项措施已经执行,我们正在监测结果。 工作流程引擎正在处理待决处决的队列.
所有处决都已处理完毕。 这一事件已经得到解决.
□ 导言 我们想谈谈2026年7月27-28日一起影响词形结构的事件的细节。 在此期间,下Gen Workflow引擎中的工作流程处决无法取得进展并一直被"执行"状态所困. 事件中没有丢失任何数据。 这一死后事件解释了问题解决后发生的情况,以及我们为防止再次发生这种情况所采取的步骤。 □ 时间线 * 2026年7月27日18:55 CEST** - 随着数据库查询性能的退化,工作流程引擎开始产生出错. 工作流处决停滞不前并停止了进展。 * 2026年7月27日20:54 CEST** - 首次收到客户报告 死刑被"执行"。 * 2026年7月27日22:39 CEST** - 事件被正式宣布. * ** 2026年7月28日02:18 CEST** – 服务重启提供临时缓解;工作流程处决恢复. * ** 2026年7月28日05:15 CEST** - 由于数据库运作问题依然存在,这一问题一再出现。 * 2026年7月28日09:56 CEST** - 查明并处理了根源。 死刑没有丢失;然而,由于部分恢复服务,处决中的一些行动被重新审判,这可能导致少数死刑未能成功。 * ** 2026年7月28日13:46 CEST** - 已证实已清理了所有积压的已停顿的处决。 该制度被宣布为稳定。 * 2026年7月28日13:48 CEST** – 事件解决. □ 根源 造成这一事件的原因是工作流程调度系统所使用的数据库索引中逐渐膨胀。 这些特定指数的性能随时间推移而逐渐退化,因为它们积累了以前写作和更新的已死指数条目. 任务调度引擎在查询这些索引以确定要发送的工作时,会获得数据库级别的协调锁. 随着索引的查找速度越来越慢,它们开始超过数据库所配置的语句超时. 当检查被超时取消时,负责这项工作的排程进程崩溃并重新启动. 由于没有运行计时器,无法发出工作流程步骤,所有进行中的工作流程执行都陷入困境。 在整个事件中,数据库服务器本身保持了健康,具有正常的CPU和连接水平. 问题完全是日程安排层内部的锁和延迟争论。 一个服务重启清理了已崩溃的进程并临时恢复执行 。 然而,由于指数bloat仍然存在,一旦恢复了查询负荷,同样的降解就会再起. 人工指数重建了完全恢复的性能并解决了这个问题. □ 防止再起的行动 1. ** 增加自动指数维护** -- -- 已为受影响的指数安排了定期自动指数维护。 这确保了bloat不能随着时间的推移而积累,并消除了引发这一事件的条件. 2. ** 已删除Legacy指数** -- -- 已查明并删除未使用的遗留数据库指数,从而减少了整体维护面并简化了未来的指数卫生。 3. ** 监测覆盖面得到更新** - 目前正在审查和更新我们的监测情况,以反映工作流程引擎的现状。 这项工作将缩小差距,从而在第一次客户报告之前无法发现退化情况.
自动翻译自官方事件更新。
工程与Orchestrator发现一个问题,即新的工作流程引擎目前没有执行工作流程. 问题正在调查中.
所有工作流程都按预期再次被执行.
□ 导言 我们想谈谈2026年7月27-28日一起影响词形结构的事件的细节。 在此期间,下Gen Workflow引擎中的工作流程处决无法取得进展并一直被"执行"状态所困. 事件中没有丢失任何数据。 这一死后事件解释了问题解决后发生的情况,以及我们为防止再次发生这种情况所采取的步骤。 □ 时间线 * 2026年7月27日18:55 CEST** - 随着数据库查询性能的退化,工作流程引擎开始产生出错. 工作流处决停滞不前并停止了进展。 * 2026年7月27日20:54 CEST** - 首次收到客户报告 死刑被"执行"。 * 2026年7月27日22:39 CEST** - 事件被正式宣布. * ** 2026年7月28日02:18 CEST** – 服务重启提供临时缓解;工作流程处决恢复. * ** 2026年7月28日05:15 CEST** - 由于数据库运作问题依然存在,这一问题一再出现。 * 2026年7月28日09:56 CEST** - 查明并处理了根源。 死刑没有丢失;然而,由于部分恢复服务,处决中的一些行动被重新审判,这可能导致少数死刑未能成功。 * ** 2026年7月28日13:46 CEST** - 已证实已清理了所有积压的已停顿的处决。 该制度被宣布为稳定。 * 2026年7月28日13:48 CEST** – 事件解决. □ 根源 造成这一事件的原因是工作流程调度系统所使用的数据库索引中逐渐膨胀。 这些特定指数的性能随时间推移而逐渐退化,因为它们积累了以前写作和更新的已死指数条目. 任务调度引擎在查询这些索引以确定要发送的工作时,会获得数据库级别的协调锁. 随着索引的查找速度越来越慢,它们开始超过数据库所配置的语句超时. 当检查被超时取消时,负责这项工作的排程进程崩溃并重新启动. 由于没有运行计时器,无法发出工作流程步骤,所有进行中的工作流程执行都陷入困境。 在整个事件中,数据库服务器本身保持了健康,具有正常的CPU和连接水平. 问题完全是日程安排层内部的锁和延迟争论。 一个服务重启清理了已崩溃的进程并临时恢复执行 。 然而,由于指数bloat仍然存在,一旦恢复了查询负荷,同样的降解就会再起. 人工指数重建了完全恢复的性能并解决了这个问题. □ 防止再起的行动 1. ** 增加自动指数维护** -- -- 已为受影响的指数安排了定期自动指数维护。 这确保了bloat不能随着时间的推移而积累,并消除了引发这一事件的条件. 2. ** 已删除Legacy指数** -- -- 已查明并删除未使用的遗留数据库指数,从而减少了整体维护面并简化了未来的指数卫生。 3. ** 监测覆盖面得到更新** - 目前正在审查和更新我们的监测情况,以反映工作流程引擎的现状。 这项工作将缩小差距,从而在第一次客户报告之前无法发现退化情况.
自动翻译自官方事件更新。
2026年6月16日01:00PM CEST至2026年6月17日11:00AM CEST之间,"词组工作同步"连接器出现性能退化. 使用默认连接类型的工作同步客户遇到故障 。 工程组确定了一个根源,并提供了固定方案.
导 言 我们想更详细地介绍2026年6月16日,01:00PM CEST至2026年6月17日,11:00AM CEST之间与Phrase Strings API一起发生的事件,这些事件导致Phrase Strings API的性能退化,导致客户使用默认连接类型的Job Sync,体验出故障. 我们对干扰事件表示歉意,并致力于防止今后发生类似事件。 时间线 ** Jun 16, 2026 @ 01:00 PM CEST ** – Job Sync开始失败,客户使用默认的连接类型. 连接器无法对 Phase Strings API 进行认证 。 ** Jun 17, 2026 @ 10:00 AM CEST** - 认证失败被工程组识别出. ** Jun 17, 2026 @ 10:28 AM CEST ** – 影响范围被确认:使用默认任务同步连接的客户受到影响. 使用个人登录信使连接器的客户没有受到影响。 ** Jun 17, 2026 @ 10:29 AM CEST** – 根由被确定:最近的一项变化增加了多平台符号支持,无意中引入了一些已存在的平台符号错误. ** Jun 17, 2026 @ 10:40 AM CEST** – 已准备并已提交审查。 ** Jun 17, 2026 @ 10:53 AM CEST** — 该固定装置已部署,JobSync功能已完全恢复。 根原因 : 为多平台认证符号添加支持而引入的代码更改,修改了进取的平台符号在Phrase Strings API中的验证和处理方式. 此更改与默认连接类型使用的现有符号格式不相兼容 。 结果,Strings API以`401 未经授权 ' 的答复拒绝了平台标志。 连接器重试建立连接,直到其重试预算耗尽,导致所有受影响的操作都失败. 使用个人访问标志的客户没有受到影响,因为他们的标志遵循不同的代码路径。 防止再起的行动 其根源是对符号处理的逆向变化,在开发过程中没有检测到. 正在采取以下行动: * ** 认证更改中的调试格式兼容性:** 在采用新的代号/认证格式和现有的代号/认证格式时,测试必须明确涵盖过渡案例——根据新的检测逻辑处理的旧格式代号——而不仅仅是孤立地处理每一种格式.
自动翻译自官方事件更新。
我们目前正在调查一个影响我们计量服务的问题,它可能导致一些客户的计量标准重复。 我们的小组正在积极努力,以查明受影响的组成部分并找出根源。 一旦获得更多信息,我们将提供进一步的最新资料.
我们已查明根源是特定经纪人的不稳定,这正在导致我们计量服务中消费者群体反复重新平衡,并导致对计量更新的重复处理。 这可能导致一些客户经历不正确的消费计算或出乎意料的账户封堵. 我们继续寻找解决办法.
我们阻止了这一问题的发展,目前正在努力确定影响的全面范围,包括哪些组织受到影响或被阻挠。 受影响的账户将通过分解程序优先解决,尽管这需要一些时间才能完成.
我们已经成功地使所有被封锁组织的计量标准减少。 我们正在继续努力制定每个组织分解工具,以确保准确的计费周期数据,明天上午,整个小组将扩大这些修复工作.
我们继续取得进展,解决7月16日首次确定的重复计量的消费问题。 已查明并解决了根源。 自从我们上次更新以来,我们的小组已经纠正了以前所有被冻结账户的重复数据。 我们现在正在处理剩下的一系列受影响的账户,并期望在今后几天中继续进行这一清理工作。 没有进一步的重复,这项工作只涉及历史数据.
这一事件已经得到解决.
自动翻译自官方事件更新。
我们目前正在调查一个影响词形兽形体的问题。 我们正在努力查明根源,并将在获得更多信息后立即提供进一步的最新资料.
我们正在继续调查这一问题.
这一问题已经确定,一个解决办法正在实施之中.
一项措施已经执行,我们正在监测结果.
自5:32 PM CEST起, Orchestrator(欧盟)再次提供. 所有待决处决正在处理中。 这一事件已经得到解决.
自动翻译自官方事件更新。
我们目前正在调查一个影响(欧盟和美国地区)语言字符串翻译中心的问题,那里的字符串无法装入。 我们的工程队已经查明了一个潜在的原因,并正在积极努力解决这个问题。 我们将随着调查的进展提供进一步的最新资料.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
## 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.
自动翻译自官方事件更新。
我们正在从用户那里得到关于从项目中消失的工作的报告,我们正在调查这个问题.
这一问题已经确定,已经解决,我们正在监测局势.
此事已决.
自动翻译自官方事件更新。
我们目前正在与CAT Web编辑器调查问题.
这一问题已经确定,已经解决,我们正在监测局势.
此事已决.
自动翻译自官方事件更新。
Hello everyone, this is a test, kindly ignore.
This incident has been resolved.
This is a test, please ignore.
This incident has been resolved.
This incident has been resolved.
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.
We are continuing to investigate this issue.
The issue has been identified and a fix is being implemented.
A fix has been implemented and we are monitoring the results.
We are continuing to monitor for any further issues.
This incident has been resolved.
