欧洲 - 文件理解 - 部分外出
Pending
- resolved
2026年10月27日,在协调世界时14:35至16:08之间,欧洲地区的Document Conference经历了部分停产,影响了基因提取,基因分类和自发性. 其根源是与第三方存储供应商的连接问题。 连接被恢复,我们已经确认,从协调世界时16:08起,提取和分类一直正常工作.
自动翻译自官方事件更新。
121 Uipath incidents · 2026年4月 — official updates, affected components, duration and resolution details.
2026年10月27日,在协调世界时14:35至16:08之间,欧洲地区的Document Conference经历了部分停产,影响了基因提取,基因分类和自发性. 其根源是与第三方存储供应商的连接问题。 连接被恢复,我们已经确认,从协调世界时16:08起,提取和分类一直正常工作.
自动翻译自官方事件更新。
我们目前正在调查一个影响获得真知灼见和自动化业务服务的问题。 我们的小组正在积极评估局势,以找出根本原因,并确定恢复正常业务的必要步骤。 一旦获得更多信息,将提供进一步的最新资料.
自动化行动的问题已经解决。 我们目前正在等待“洞察”服务问题得到缓解。 进一步更新一旦完成,将予分享.
在新加坡、日本、瑞士、加拿大、印度、联合王国、欧洲、美国、阿联酋、韩国和澳大利亚地区的深入观察服务是固定的,我们正在其他区域实施固定
这个问题已经解决,目前所有服务都正常运行.
自动翻译自官方事件更新。
2026年10月26日,在协调世界时10:20至17:30之间,自动化云机器人(VM)遭遇了影响机器运行的部分停机. 在这个窗口中,诸如启动、停止或提供VM机等动作可能尚未完成,这些机上预定的工作可能被推迟或有故障。 原因是对基本基础设施资源的一个子集的许可配置不当。 我们的团队确定了问题,纠正了配置,并证实机器操作自协调世界时17:30起正常运行. 我们正在审查如何引入错误配置,并增加检查,以防止再次发生。 您一方无需采取任何行动。 如果您还在窗口中看到失败或卡住的工作, 请重试, 如果问题仍然存在, 请联系支持 .
自动翻译自官方事件更新。
在协调世界时10月23日20:42至21:19之间,欧洲的一些Orchestrator客户看到反应缓慢并间歇出错. 这包括机器人呼叫以获取资产,处理队列项目并报告工作状况. 一些无人照顾的工作可能在此期间失败了. 原因是负荷突然增加,达到数据库的资源限度。 我们增加了数据库容量,而且自协调世界时21:19起,性能已经恢复正常. 在此窗口中工作失败的客户可能需要重新启动 .
自动翻译自官方事件更新。
我们为澳大利亚地区的客户确定了一个影响IXP的问题。 自协调世界时10:24起,使用双子座2.5闪电模型的请求在这一地区正在失败. 其他模式没有受到影响。 客户数据继续只在澳大利亚境内处理。 我们正在和Google合作恢复服务
已部署一个固定装置,服务正在恢复。 我们正在监测该系统,以确保全面恢复。 不久将分享进一步的最新情况
初期恢复后,服务再次退化. 我们正在调查并努力寻求解决。 一旦获得进一步的最新资料,我们将予以提供.
我们联系了Google Support公司 他们已经开始调查了 我们会不断监控 分享最新消息.
我们正在观察双子座2.5闪电流量的改善。 我们正在监控谷歌的可能的修复.
问题由谷歌解决.
□ 客户影响 2026年10月22日协调世界时上午10:24至2026年10月22日协调世界时下午6:04,澳大利亚地区使用双子座2.5 Flash的文件处理请求因容量出错而失败. 撞击持续了约7小时40分. 该区域使用文件提取工作流程的少数客户受到影响。 在一次临时的区域内回落尝试中,一些取出请求被短暂地恢复,但词层归属和生成的页面文本被退化,直到回落也开始失败. □ 根源 其根源是同时维护期间供应商方区域网络中断。 这导致供应商的模型服务环境出现严重的带宽减速,使后端系统无法在受灾地区装入为双子座2.5 Flash和双子座3.5 Flash提供可靠服务所需的模型数据. □ 检测 这个问题是通过自动警报发现的,该警报在澳大利亚地区双子座2.5闪光灯上发现了限制费率的错误。 我们的工程小组通过遥测确认,受影响的请求一直失败并开始协调反应。 □ 回应 UTC下午1点40分,我们将双子座2.5闪电到同一区域内双子座3.5闪电,以保留数据居住权. 最初的遥测显示该变化后没有能力出错,但到UTC下午2点10分,双子座3.5 Flash也在还原容量错误,因此倒计时不再可行. 在协调世界时下午2点05分,我们调整了相关的文件处理路径,因此归属和页面文本生成将使用同样的区域回落;该调整在协调世界时下午2点09分左右完成。 在倒计时也失败后,我们恢复了路线变化,到UTC下午4:28时,交通恢复了预期的双子座2.5闪电道. UTC下午5点38分,遥测显示双子座2.5闪光成功率提高. 从协调世界时6:04起,没有观察到进一步的容量出错,随后的请求成功. □ 跟进 1. 利用观察到的交通模式完成对受影响地区的保留模式能力评估 2. 评价文档处理客户端的再试和后退行为,以减少在提供者-侧容量故障时再试放大.
自动翻译自官方事件更新。
自协调世界时约11:17起,多个地区的客户就经历了UiPath代理和解决方案管理的问题. 新工作可能仍然处于待决状态,在处理升级或等待工具结果时,运行的代理可能遇到延误。 我们正在调查这一问题并努力寻求解决办法.
这一问题已经得到缓解。 我们正在监测各区域受影响的服务,以确保稳定,并证实工作开始和解决办法的部署是正常运作的.
这一事件已经得到解决。 UTC10月15日11:15至12:45之间,一个内部配置问题使得UiPath服务之间的一些事件无法跨多个区域交付. 这个问题通过减少变化得到了解决,正在正常处理新的活动。 在这一窗口中开始或进行的一些工作可能需要注意: - 代理人:等待行动中心任务或自动化工具结果的代理人可能会被困住。 从Orchestrator开始的工作也可能出现卡住或停工。 - Maestro:等待用户任务的过程在任务完成后可能无法恢复. - Apps:队列项状态可能已经过时,由队列项完成所触发的行动可能还没有运行. - 人人自动驾驶:等待自动化结果的对话可能仍然停滞不前。 - 文件理解和背景定位:等待取出、验证或索引的自动化和代理人可暂停。 - 整合服务:连接器事件可能没有触发预期的进程或通知。 - 解决方案和工作室Web:解决方案安装,卸载,发布,部署,以及此窗口期间启动的验证可能失败或超时. 重新试验这些行动可以解决问题。 我们为干扰道歉,并感谢你的耐心.
** 客户影响** 2026年10月15日,协调世界时11:15至12:50(约合1小时35分),UiPath云服务间交换出的一些事件未能交付. 所有商业云区的客户都受到影响。 在此窗口中 : - 新的特工可以留在待决状态 等待工具结果、人员升级、文件取出或上下文的运行人员可能无法恢复。 - 启动自动化的每个人谈话的谈话代理人和自动驾驶员可能没有收到结果。 - 等待用户任务的Maestro进程实例在任务完成后可能没有取得进展,整合服务连接器事件触发的进程可能还没有开始。 - 显示或响应队列项目状态的应用程序可能显示已过时的信息。 - 解决方案安装、卸载、发布和部署可能失败或中断。 - 一些用户、组和文件夹在窗口中所做的修改可能并未向所有服务推广。 UTC下午12:50后开工,没有受到影响. 在Orchestrator内部处理的机器人任务执行、排队和触发器保持正常工作。 ** 循环原因** 我们正在将内部服务配置的交付转移到一个新的机制,这一改变意在对客户没有任何影响。 当这一改变被应用到事件交付服务时,它所产生的配置缺失了所需的值. 没有它,服务就把几种产品集成视为关闭,默默地停止了活动。 由于这一变化同时影响到所有生产地区,因此每个地区都受到影响。 ** 检测** 这个问题在协调世界时11:51(撞击开始后约35分钟)发现,当时监测对仍在待决状态的代理工作发出警报。 之后有报道称解决方案部署时间出炉,并于协调世界时12:12宣布出事. ** 答复** 在协调世界时11:51进行首次检测后,识别出配置变化,并开始于协调世界时12:00回滚. 在协调世界时12:14起的初步回滚并未完全恢复交付. 团队随后停止了新的配置交付过程并恢复了之前的配置. 事件交付于协调世界时12:40开始恢复,所有区域的全面恢复于协调世界时12:50得到确认. 在可能情况下,我们重现了错过的事件,以便继续受影响的工作。 ** 后续行动** 1. 为受影响的服务暂停了新的配置交付进程,并将暂停,直到生成正确配置。 2. 验证新交付机制在适用于任何环境之前对所需值作出的配置。 3. 逐步改变各区域的配置交付,而不是同时改变所有区域。 4. 改进我们的监测工作,以在几分钟内发现事件停止交付给通常接收到的产品集成。 5. 提高我们恢复和重复在中断期间所错过的事件的能力.
自动翻译自官方事件更新。
美国地区一些客户在机器人日志摄入过程中出现延迟,观测到的活度在协调世界时约11:20至11:45之间. 这个问题已经解决,日志摄入已经恢复正常. 谢谢你的耐心.
□ 客户影响 2026年10月15日 UTC晚上11点20分左右到2026年10月15日 UTC晚上11点45分左右,美国东部地区一些客户在UiPath Orchestrator的机器人日志摄取被延误. 在受影响期间,机器人日志没有更新。 撞击持续了约20分钟. □ 根源 在这起事件中,在13起处理机器人日志摄入的服务事件中,有2起没有与事件摄入服务连接。 只有对事件摄取服务的要求没有得到满足,只有这两种情况。 这导致一些机器人日志摄取请求未能成功完成,导致受影响的客户日志数据被延迟. 事件期间没有确定只有这两起事件与事件摄入服务失去连接的根本原因。 该小组承诺对受影响事件的日志进行事件后审查,以查明其根本原因。 我们认为,这是我们云层提供者未报告的基础设施问题。 □ 检测 这个问题在协调世界时2026年10月15日晚上11:33左右通过自动警报被检测出,并通过遥测显示两个被影响的服务例的例外来确认. □ 回应 经检测,遥测确认,只有两个服务情况产生例外情况。 反应器将这两起不健康事件从服务中移除,替换事件自动开始。 在第一次警报后大约20分钟内——在协调世界时晚上11点53分左右——遥测显示恢复和合成监测检查正在通过。 已考虑在更大范围内重新启动所有服务项目,但没有进行,因为小组确定,在未首先了解其根本原因的情况下,不应继续进行。 □ 跟进 1. 事件后对受影响服务案例记录的审查显示,问题与基础设施有关,我们正在与云基础设施供应商进行后续调查,了解更多细节。 2. 如果调查得出进一步结论,将公布最新情况.
自动翻译自官方事件更新。
从UTC早上6点50分开始, 我们经历了全球停电, 外出问题已经解决,各项服务全面开通. 影响:没有持续的用户影响.
从UTC早上6点50分开始, 我们经历了全球停电, 外出问题已经解决,各项服务全面开通. 影响:没有持续的用户影响.
□ 客户影响 在协调世界时06:38至协调世界时2026年10月14日07:21之间,对UiPath Apps,Coded Apps的部分请求,以及依赖这些请求的解决方案在11个地区都失败了:欧洲,美国,共同体,日本,新加坡,澳大利亚,加拿大,韩国,瑞士,阿联酋,以及延迟的美国环境. 印度和联合王国地区没有受到影响。 总体而言,约有2%的请求失败,视区域而定,在0.6%至5%之间。 受影响的用户看到应用程序无法加载,请求返回服务器出错,或反应缓慢. 在必须重新启动服务舱的区域,Apps在8分钟左右无法到达. 到协调世界时07:40,每个地区的反应时间都恢复正常. 大多数已经运行的已发布应用程序的用户注意到很少或根本没有. App定义在浏览器中被缓存了最多24小时,App数据来自Data Service和Orchestrator,而不是这个数据库,并且该服务一直使用它已经持有的数据库连接. 失败的请求是需要新数据库连接的请求:打开设计者或应用程序列表,装入尚未缓存的应用程序,下载Apps存储的文件和图像,保存或发布. □ 根源 协调世界时06:38,在为新的区域部署设置数据库访问权限的同时,Apps服务使用的数据库用户密码被更改. 该用户由所有受影响区域的制作数据库集群共享,因此这一变化一并适用于所有区域。 运行中的服务仍然持有先前的密码,无法再打开新的数据库连接. 印度和联合王国地区没有使用这种证书,也没有受到影响。 这一改变旨在为新区域创建一个单独的数据库用户。 相反,所有区域共用的现有用户的密码都发生了变化。 我们的数据库证书的更改过程并没有明确地将建立新的证书与修改现有的证书分开,也不要求检查证书更改会影响到多少组和区域。 这再加上一个单一数据库用户在各区域之间共享,使一个区域能够改变,造成多区域停用。 □ 检测 我们的内部监测在协调世界时06:41发出第一次警报,在第一次故障发生后3分钟,每个受影响地区的警报在协调世界时06:46发出。 协调世界时6:50,待命工程师证实其数据库拒绝每个生产集群,并开始了事发过程。 □ 回应 协调世界时07:05恢复了之前的密码,并停止了各地的认证故障. 大多数区域自动重新连接。 在没有恢复的地区,服务舱被重新启动或重新部署: UTC07:21延后了美国和瑞士到UTC07:30. 请求失败在协调世界时07:21停止,响应时间在协调世界时07:40恢复到基线,我们继续监视,直到协调世界时07:43解决了事件. □ 跟进 为了防止这种情况再次发生,我们: - 采用建立和轮换数据库证书的明确程序,并进行修改前审查,说明哪些集群和区域分享证书,并在一个区域分阶段推出证书,然后加以核查,然后才能更广泛地适用。 - 将每个区域的数据库用户分开,比例最低,这样一个区域的变化不会影响另一个区域。 - 在几个地区同时发现同一数据库出错时,自动宣布事件并呼叫数据库所有者,而不是依靠单个区域警报的人工升级。 - 使服务能够在不重新启动的情况下接取更新的数据库证书,并在认证失败后更快地重新连接.
自动翻译自官方事件更新。
目前,我们正在调查影响多个地区维帕斯云服务的停电事件。 用户无法获得在受影响地区托管的服务。 下一次更新:一旦得到更多信息,将予以分享.
我们正在继续调查这一问题.
一项措施已经执行,我们正在监测结果。 发行范围仅限于文档理解,计算机视野,语义代理,自动驾驶所研究,IXP. 一旦服务全面恢复,我们将分享另一个最新情况.
一项措施已经执行,我们正在监测结果.
这一事件在过期的SSL证书续签后得到解决,该证书影响了多个依赖ML的服务,包括IXP,文档理解,计算机视野,语义代理和开发者自动驾驶. 服务恢复在受影响地区取得了进展,并配置了自动警报,以帮助提前发现证书过期,并防止今后发生类似的中断。 谢谢你的耐心和理解.
□ 客户影响 在协调世界时2026年10月13日13:37至14:40之间,多个地区的客户无法使用IXP无结构文档,IXP通信矿业和文件理解. 依赖于同一机器学习服务的开发者的计算机视觉和自动驾驶功能也失败了. 受到影响的客户看到请求失败是因为"500 Internal Server Error"的响应或超时,IXP项目不会打开,计算机视野活动运行自动化失败. 服务中断了大约一个小时。 没有客户数据丢失。 □ 根源 造成这一事件的原因是一份过期的安全证书,用以建立与这些服务的安全联系。 证书通过自动程序更新 。 这个过程不再成功执行,失败没有发出警报,因此证书在过期前没有被替换. 从协调世界时13:37起,与受影响服务的安全连接被拒绝。 □ 检测 自动监测在协调世界时13:40开始对错误和缺失流量发出警报,事件于协调世界时13:54宣布. 已过期的证书于协调世界时14:00确定,第一次状态页面更新于协调世界时14:03发布. 没有警示警告证书即将到期,自动更新的屡次失败没有向自有团队报告,因此只有在客户受到影响时才会发现问题. □ 回应 UTC下午14:06分,球队确认该证书已过期,因为自动续签失败. 在协调世界时14:18,为续约过程颁发了新的证书. 更新工作于协调世界时14:19人工启动,于协调世界时14:33完成,至协调世界时14:37,每个客户端都经过验证为更新后证书服务. 交通在协调世界时约14:40恢复到正常水平. 经过一段时间的监测后,事件于协调世界时15:19得到解决. □ 跟进 为了帮助防止今后发生类似事件,我们正在作出以下改进: - 提前很早就通知这些证书即将到期。 - 自动更新失败时通知所属小组。 - 一旦与这些服务的安全连接失效,就增加检查警报。 - 加强证书更新过程及其依赖的证书的所有权.
自动翻译自官方事件更新。
我们正在调查机器人行刑记录 不出现在Orchestrator的问题 我们正在努力确定全部范围和根源.
这个问题已经得到解决。 机器人行刑日志同步,在Orchestrator再次为日本Orchestrator可见. 谢谢你的耐心.
□ 客户影响 在协调世界时2026年10月9日7:00左右至协调世界时2026年10月13日10:45之间,日本地区约6%的客户机器人日志条目没有出现在Orchestrator. 工作执行和所有其他Orchestrator功能没有受到影响。 问题确定后,Orchestrator中出现了缺失条目。 □ 根源 机器人日志被放入一队分出32个分区,一个摄入服务会读取每个分区并存储Orchestrator的日志. 10月9日,日本地区的摄入服务停止从32个分区中的2个分区读取,没有报告出错. 这些分区上的日志被保留在队列中,但没有被存储,因此没有出现在Orchestrator上. 我们的监测检查了整个服务,而不是每个分区,所以这个问题没有被自动检测出. □ 检测 通过客户报告发现了这一问题。 我们于协调世界时10月13日10点13分宣布出事,并于协调世界时10点32分张贴了状态页通知. □ 回应 我们大约在协调世界时10:41重新开始摄入服务,它恢复阅读所有分区. 队列中所持有的日志随后被处理后在Orchestrator上被取出. 事件于协调世界时10:57解决. □ 跟进 * 我们正在增加监测,以便在任何单一分区停止阅读时提醒我们,因此这种问题在几分钟内就被发现.
自动翻译自官方事件更新。
我们正在调查关于美国高科技公司任务产生失败的停电报告。 影响:用户可能无法创建HITL任务. 下一次更新:我们的团队正在努力了解原因和范围,并将分享现有更新.
我们已查明造成美国大师HITL任务产生停工的原因,并正在努力缓解这一问题。 影响:用户可能无法创建HITL任务. 下一次更新:我们的团队正在努力缓解这一问题,并将分享现有更新.
并致力于缓解这一问题。 影响:用户可能无法在Maestros内部创建HITL任务,并配置了HITL任务 SLA定时器. 下一次更新:我们的团队正在努力缓解这一问题,并将分享现有更新.
由美国配置的 HITL 任务 SLA 计时器为Maestro 创建 HITL 任务而影响问题的解决方案已经全面推出。 HITL 任务创建已恢复正常.
□ 客户影响 2026-10-05 UTC早上9点30分 - 2026-10-07 3点30分 UTC,Maestro BPMN 和 Case 客户使用配置了任务计时器的 HITL 节点,在 HITL 阶段看到了他们的调试和生产事件失败,有 4xx . 在美国和欧洲各地的客户中发现了大约30起此类事件,但无工可做。 □ 根源 配置任务 SLA需要一个对象,包括开始和结束的标准, SLA的定时器,以及 SLA 突破的结果. 客户在HITL节点上的大师设计器上配置了这个. 其结果被错误地保留了非强制性的设计表面,尽管没有结果的 SLA 配置并没有坚持下去,也没有商业意义. 行动中心后端小组增加了一个验证,以便在SLA非无效物体出现缺失结果时提出错误请求(400个)。 这最终影响到那些在节点上添加起步/结束标准但没有配置结果的客户。 先前运行的400起事件失败,无法恢复 □ 检测 一名顾客向Maestro Engineering SME提出了这个问题,后者在内部向团队提出了这个问题. 大师团队调查了这起失败事件,观察到USI的失败事件越来越多,还有少数其他租户通过日志,导致他们与行动中心团队接触. □ 回应 马斯特罗小组通过电子邮件从客户那里收到关于该问题的报告,他们进行了一些初步调查并查明了潜在的倒退,随后,行动中心与中小企业进行了接触,在较低环境上复制了这一问题,对特征进行了回滚并进行了测试,并推广到所有受影响地区。 这个问题已经解决,所有情况都在内部重新审理和恢复。 □ 跟进 1. 在所有跨服务代码库表面增加验证,以确保人审查 2. 增加必要的监测和一体化测试,以更快地发现这一问题
自动翻译自官方事件更新。
我们正在调查有关美国东部自动化云区一些组织间歇性缓慢和出错的报道。 受影响的用户可能在 Orchestrator UI 中看到页面无法加载(例如返回"出错"的Jobs页面),而队列交易和会话启动等机器人操作可能间歇性地暂停. 一旦获得更多信息,我们将立即提供最新情况.
我们提高了美国东部地区受影响的数据库基础设施的能力,误差率和延迟率恢复到正常水平。 一旦获得更多信息,我们将立即提供最新情况.
我们东美国地区的问题 误差率和延迟率恢复到正常水平.
□ 客户影响 在协调世界时2026年10月7日约下午1:00至18:15之间,美国地区的顾客在Orchestrator中经历了间歇性出错并反应缓慢. 受影响的用户可能已经看到 Orchestrator 页面无法加载,例如返回“出错”的Jobs 页面,诸如队列交易和会话启动等机器人操作可能间歇地超时了。 其他依赖Orchestrator(英语:Orchestrator)的UiPath服务在此期间也可能出现了反应较慢或出错. □ 根源 经常使用的一些Orchestrator操作都依赖于数据库内共享的短寿命资源,包括每个运行的机器人执行的例行状态检查. 随着本区域同时进行的机器人活动量的增加,开始要求排队使用共享资源,而不是完成工作。 其影响是选择性的,而不是一般的减速:使用这种资源的行动被推迟,而另一些则继续正常运行。 由于数据库的处理器、内存和储存使用都保持在正常范围内,例行的能力监测没有表明存在问题。 □ 检测 我们的自动监控在客户撞击开始后35分钟内检测到了这种退化现象,我们的工程师在事件期间发现了潜在的争论. 由于这是一个争论问题,而不是能力不足,而且所有能力指标都是正常的,因此预计数据库能力的增加不会解决,因此小组在应用之前就调查了各种替代办法。 这一评估推迟了缓解行动。 □ 回应 我们的工程小组提高了受灾数据库的能力。 反应时间和出错率立即恢复正常,我们继续进行监测,以确认在事件收尾前服务情况稳定. * 下午1:00:美国地区客户的错误率和反应时间开始上升。 * 13:36:自动监测检测退化情况并通知待命工程队。 *13:36–17:29:工程师调查. 所有标准数据库容量指标——处理器,内存和存储——在整个过程中都保持在正常范围内,因此从日常监测来看原因并不明显. *17:29:宣布正式出事,全员响应小组接战. 17:38 在[UiPath Status]上发布公告(http://status.uipath.com/) \(调查\). * 17:31–17:43:为受灾地区提供额外的数据库能力。 * 18:00:错误率、反应时间和请求延迟恢复到正常水平。 * 18:11:状态页被更新到监控和客户撞击结束. * 19:06:持续监测证实服务稳定后,事件结束. □ 跟进 为了防止这种情况再次发生,我们: * 改变受影响的业务,使其不再依赖共享资源。 这已推广到所有受影响的系统,并大大减少了造成这一事件的条件。 * 能够对这些系统进行详细的数据库监测,因此,在进行时而不是在以后,这种争论是显而易见的。 * 改进我们的警报,使这种真正的退化明显有别于例行的、自我纠正的变异,并更快地升级.
自动翻译自官方事件更新。
我们正在调查有关欧洲Orchestrator停电[影响功能或用户症状]的报告。 影响:用户可能期望机器人日志被摄入和/或搜索/播放日志被延迟. 没有日志丢失 。 下一次更新:我们的团队正在努力了解原因和范围,并将分享现有更新.
我们已查明了造成欧洲Orchestrator机器人日志摄入量下降的原因。 影响:用户可能期望机器人日志被摄入和/或搜索/播放日志被延迟. 没有日志丢失 。 下一次更新:我们的团队正在努力了解原因和范围,并将分享现有更新.
我们缓解了影响欧洲Orchestrator机器人原木摄入的问题。 影响:用户可能期望机器人日志被摄入和/或搜索/播放日志被延迟. 没有日志丢失 。 下一次更新:我们的团队正在努力了解原因和范围,并将分享现有更新.
我们缓解了影响欧洲Orchestrator机器人原木摄入的问题。 影响:用户可能期望机器人日志被摄入和/或搜索/播放日志被延迟. 没有日志丢失 。 下一次更新:我们的团队正在努力了解原因和范围,并将分享现有更新.
□ 客户影响 大约在协调世界时15:45到协调世界时18:45之间,在欧洲,澳大利亚和日本地区的客户无法在Orchestrator看到最近的机器人日志. 撞击窗口期间所写的日志没有出现在"Jobs"和"logs"视图中,也没有通过"机器人日志"API出现,而当天在协调世界时约03:00以上的日志只能断断续续地提供. 影响窗口因区域而异: - 澳大利亚:协调世界时约15:45至协调世界时18:35 - 欧洲:协调世界时16:35-18:00 - 日本:协调世界时16:45至协调世界时18:30 任务执行,队列,触发器和所有其他Orchestrator功能没有受到影响. 没有机器人日志丢失。 在撞击窗口期间生产的日志继续被收集,一旦问题得到缓解,就再次显出. □ 根源 我们正计划进行一个升级 用于存储 Orchestrator机器人日志的弹性搜索服务。 升级采用蓝色/绿色方法:与现有方法一起创建出一个新的集群,数据从备份中恢复到其中,摄入新日志的管道在它上启动,只有在那时,流量才被切换. 在受灾地区,在数据恢复并完成摄入补正之前,运行升级的工程师批准了流量开关,这偏离了我们的升级程序. 这是人为的错误。 因此,Orchestrator正在从一个尚未包含最新数据的集群读取机器人日志,而新的日志仍在被收集,但尚未在集群服务请求上索引. 错误没有被捕获,因为我们的部署工具依赖于操作员验证数据的完整性,并且没有执行数据恢复和流量开关之间的命令. □ 检测 我们的合成监测持续进行测试工作并核实其日志被退回,在受影响地区检测出缺失的日志,并提高了警报。 我们的工程小组把警报与在建工程升级联系起来,宣布了事件并公布了状态页通知。 □ 回应 我们的工程小组将交通量恢复到所有三个区域的先前的Elasticsearch集群,这些集群立即恢复了所有机器人日志的准入,包括撞击窗口期间生产的日志。 我们确认,在协调世界时18:45左右,通过对每个受影响地区的合成监测,并在对事件进行标记之前,继续进行监测。 新的集群的升级继续在背景中进行。 只有在数据恢复完成并证实摄入情况符合最新要求之后,才能向它们转移流量。 □ 跟进 为了防止这种情况再次发生,我们: - 改变部署管道,以便在数据恢复和记录对新集群的摄入完成前,交通开关无法运行。 - 在管道上增加自动回滚步骤,因此,如果在开关后发现问题,可以在几分钟内将流量返回到前一组.
自动翻译自官方事件更新。
我们观测到阿联酋服务业绩下降
我们目前正在调查这一问题.
我们把这一问题确定为与第三方服务提供商的网络线路问题,影响到我们设在阿联酋的服务互联互通。 我们正在同我们的上游提供者就解决问题进行合作,并将在这方面更新进展.
我们正在继续努力解决这个问题。
我们正在监测连通性,一旦稳定得到确认,我们将更新这一页.
我们正在继续监测任何其他问题.
此事已决.
□ 客户影响 UTC下午12:38至2:51 PM UTC之间,阿联酋地区一部分客户在访问UiPath云服务时遭遇了故障. 事件持续了大约2小时13分。 受影响的服务包括使用**cloud.ipath.com**,**access.ipath.com** 设在阿联酋的服务。 客户可能遇到超时,认证失败,重设连接,或服务器出错. □ 根源 其根源是第三方基础设施供应商的区域网络线路故障。 从UAN区域到特定外部网络(包括服务于**cloud.uipath.com**和**account.uipath.com**的内容提供网络)的出站网络路径子集停止提供流量。 来自受影响服务的新的外出连接尝试没有得到回应,导致请求超时。 我们的工程团队排除了UiPath服务配置,应用级政策和出站连接能力作为原因. 基础设施供应商承认,一个已知问题影响到同一网络路径上的多个客户。 □ 检测 通过自动监测发现了这一问题。 到UTC下午12点40分左右——大约在故障开始后两分钟——调查证实,受影响的UAN区域服务与UiPath关键端点的新连接正在失败. □ 回应 到UTC下午1点20分,我们的工程组确认故障仅限于特定的出入口网络路径,而其他目的地仍然可以到达. 校验排除了UiPath-side路由变化,内容提供配置变化,应用程序级政策,以及出站连接容量问题. 与第三方基础设施提供商一起开启了高强度支持案件。 在协调世界时下午1点50分,供应商承认了影响多个客户的一个已知问题。 我们的小组继续监测受影响网络路径的恢复情况,并在交通返回时核查服务健康状况。 UTC下午2点51分,恢复检查确认通过受影响内容发送路径的UiPath流量已恢复到正常水平. 自动健康检查和服务衡量标准证实已恢复,在乌安的服务已开始运作。 □ 跟进 1. 我们正在推行基础设施提供者确认的纠正行动和对区域线路故障的根本原因分析。 2. 我们正在审查受影响地区外出服务依赖性,以加强抵御类似第三方网络中断的复原力.
自动翻译自官方事件更新。
自UTC下午15:05起,美国地区的一些顾客可能会看到在Cloud Robots上运行的工作需要比平时更长的时间才能开始,或者停留在等待状态. 机器人上的工作不受影响,其他区域也不受影响。 我们找到了可能的原因 并正在努力恢复正常的工作处理 已经排队的工作不会丢失,一旦问题得到解决,将予以处理。 我们将在60分钟内发布另一个更新.
我们用一个固定的方法来解决 推迟在美国地区 云机器人公司的工作, 工作开始正常。 被拖延的工作目前正在处理中。 我们正在监控 以确保服务保持稳定 并且将在60分钟内发布另一个更新.
在进一步研究这个问题之后,美国地区的 " 云机器人 " 工作现已正常开始。 先前拖延的工作正在处理之中。 我们继续监控服务,一旦问题解决,我们将再次发布最新消息.
这个问题已经得到解决。 在协调世界时15:05至16:39之间,美国地区的"云机器人"(Cloud Robots)的工作开始或停留在"待定"州的工作进展缓慢. 自协调世界时16:39起,工作正常开始,在此期间被拖延的工作现已得到处理。 我们为中断道歉.
□ 客户影响 UTC2026-10-02下午3:00至16:38分,云机器人在美国地区的工作开始时间比平时要长,在UTC16:20左右的高峰时间可达22分钟. 兽医可以继续工作,没有失业,没有其他地区受到影响。 少数客户在等待前期工作时收到新提交的临时限制错误。 □ 检测 协调世界时15:07起自发警报,撞击开始后7分钟. 美国地区的检查在协调世界时15:32左右失败,事件响应开始. □ 根源 UTC下午14:55,一位客户的工作流程开始以约20倍的正常速度提交工作. 允许工作的服务在数据库中保留每个客户的货币计数,并在每个工作开始和结束的数据库锁下更新。 以这个速度,客户记录的锁定队列增长到更新超时. 等待更新占据了为本地区所有客户创造就业的共享的工人池,因此每个客户的工作都在他们后面等待. 旨在隔离一个客户负荷的机制成为了瓶颈. □ 回应 团队确定了超负荷入院路径及其背后的工作量. UTC下午15:46第一次配置改变针对错误记录,没有效果. 在协调世界时16:10正确更改后,该客户的工作类型免于数据库锁,并于协调世界时16:20左右生效. 起步时间从约13秒下降到不到一秒,积压的约5200个工作在18分钟后排出. 协调世界时16:38开始工作是正常的。 客户的触发器在协调世界时16:40左右被与客户关闭. □ 跟进 被数据库锁定的速率限制被模拟中高性能速率限制机制所取代,因此一个客户的负载不能阻断其他人的起职. 修改完成后,在同负荷的预生产中进行测试并推出.
自动翻译自官方事件更新。
我们目前正在调查影响阿联酋地区 Insights 门户网站的故障。 这一地区的用户可能无法访问该门户,或者可能遇到故障的页面负载. 我们的团队正在积极努力查明原因并恢复服务。 一旦掌握更多信息,我们将提供另一个最新情况.
我们已确定了缓解路径,并正在阿联酋地区开始倒退。 在这项工作进行期间,用户可能会在Insights门户网站上继续遇到断断续续的接入问题。 一旦回滚完成,我们将提供另一个最新情况.
阿联酋地区的Insights门户网站 正在成功装入 我们的回滚。 我们正在继续监测这项服务,以确认稳定,一旦我们相信这一问题得到充分解决,我们将提供最后的最新情况.
阿联酋地区的Insights门户网站现在在回滚后正常运行. 我们已经验证了关键门户的功能,并确认这项服务仍然健康。 这一事件现在已经得到解决.
□ 客户影响 2026年10月1日**,UiPath** Insights**在**UAE地区**的服务无法使用. 从UTC10月1日约**23:40起到UTC10月2日00:39起**,用户无法加载"Insights"仪表板:请求失败,10秒后出现出错. 关于为该地区新租户提供深入观察的要求也失败了。 中断持续了约**59分钟**。 阿联酋地区的其他UiPath服务和所有其他地区的Insights没有受到影响。 没有丢失客户数据。 □ 根源 造成停电的原因是在预定的Insights发布中装运的**配置变化**。 该改动将关于阿联酋地区Insights应用端点的**最低TLS\(运输层安全)版本**从TLS 1.2提高到了**TLS 1.3**,作为加强安全工作的一部分。 引导客户流量通向Insights的UiPath网关通过TLS1.2连接到这些端点. 一旦端点不再接受TLS 1.2,网关就再也无法打开安全连接. 尽管Insights的应用程序本身保持健康,但客户要求超时返回错误。 这一变化仅适用于阿联酋地区,因此没有其他地区受到影响。 □ 检测 这个问题被**UiPath的自动合成监测**所检测出,它不断测试从多地获得的洞察力. 第一次健康检查失败记录在协调世界时23:40. 数分钟内自动报警,待命工程组开始调查. □ 回应 工程组确认,停电仅影响阿联酋地区的"洞察". 应用程序运行正常,但客户流量没有达到。 团队追踪出故障到网关和Insights之间的安全连接步骤,并将其与发布时应用的TLS设置相链接. 在协调世界时约**:00:38**时,队伍恢复了之前在受影响的终点上的最低TLS版本\(TLS 1.2\). 合成健康检查立即开始通过,到**00:41 UTC**阿联酋地区所有"洞察"检查都健康. 小组继续进行监测,以确认完全稳定。 □ 跟进 为防止今后发生类似事件,我们正在采取以下步骤: * ** 将 TLS 更改从发布** 中移除,以便未来的部署不会重新应用,直到网关支持 TLS 1.3 结束为止. * ** 在生产前环境中针对网关**的Validate连接-安全变化,然后应用到生产中.
自动翻译自官方事件更新。
从10月1日 UTC下午1点半左右开始,一些代理公司,包括低码和编码代理公司,在使用Gemini-3.1-pro-review和gpt-4o-2024-05-13时,开始在所有区域出现故障. 在代理设计期间,这些模型也可能无法选择。 我们正在积极调查并努力解决.
我们已经查明了问题,并正在采取对策。 使用受影响模型的代理人可能继续遇到故障,在代理人设计期间,这些模型可能仍然无法选择,而部署工作已经完成.
我们恢复了引起这一问题的变化,并证实,受影响的模式再次出现。 有些代理人可能继续出现间歇性故障,而情况又会恢复。 我们正在继续监测基因3.1-预检和gpt-4o-2024-05-13的制剂设计和执行.
□ 客户影响 2026年10月1日,从协调世界时14:31至19:40,配置出一些大型语言模型的代理商,包括双子座3.1 Pro Preview和GPT-4o (2024-05-13),未能在所有地区开始,错误地说该模型没有可用. 在设计代理商时,模型清单中缺少同样的模型。 使用其他模型的代理人没有受到影响。 □ 根源 一个特性旗被翻转,导致代理服务开始发送一个操作代码来模拟发现请求. 这使得该型号清单成为该具体业务与基地物剂模型清单的对照。 每个操作模型清单最初都取自 " Bring Your Own Model " (BYOM)的超标模型配置,这对代理商来说至关重要,它与代理商服务中支持模型的完整清单并不相等。 内部审计表明这是一个错误,而不是有意的漏洞。 随着时间的推移,这一差距从未被解决,在国旗开关之后,已经配置了任何受影响模型的代理商将因不在返回的列表而失败. □ 检测 一个客户报告了这个问题,在协调世界时16:44升级为我们的工程师. 我们的监测没有发出警报,因为这一错误通常指向组织或代理级别的配置问题。 □ 回应 工程师们追踪到失败到配置改变,并在协调世界时19:01将其还原. 复出在以下几分钟内生效,最后一次失败发生在协调世界时19:40. □ 跟进 1. 在再次作出这一修改之前,将调整示范名单。 2. 我们正在改变这个错误的分类方式 所以一个全平台的突起警报 我们的工程师.
自动翻译自官方事件更新。
从10月1日 UTC中午12点左右开始,欧洲的社区用户可能会在使用溶液-局部行动Apps的LowCode Agents中遇到故障. 我们确认,影响仅限于欧洲的社区用户。 我们正在积极调查这一问题,确定失败的程度,并努力解决问题.
我们已查明造成低码代理失败的问题, 我们正在减少以前的变化并继续监测复苏情况。 一旦回滚工作完成,或者如果有更多的信息要分享,我们将提供另一个最新情况.
我们已经确认,回滚已经完成,影响欧洲社区用户使用解决方案-地方行动应用程序的低码代理的问题已经得到解决。 服务恢复了,我们正在结束这一事件.
□ 客户影响 2026年10月1日,从协调世界时10:50到19:50,欧洲一些 Studio Web用户无法调试将Orchestrator process(RPA,代理等)或Action Apps调用同一解决方案的代理. 调用失败, 出现"未找到" 错误 。 出版代理和生产工作没有受到影响。 □ 根源 一个 Studio Web 更新在调试过程中改变了解决方案资源的位置. 它缺少了保存上一个行为的设置,因此调试运行在用户的个人工作空间中寻找解决方案的资源,而不是调试文件夹. □ 检测 自动端到端测试在协调世界时16:43提示了我们的工程师. 端到端测试套件每2小时运行一次,只有在连续3次测试失败后才会发出警报. 客户环境也报告了这一问题。 □ 回应 在查明了根源后,于协调世界时18:00开始回滚,并于协调世界时19:50全面生效. 这一期限包括部署失败,必须经过再试,需要50分钟。 10月2日协调世界时下午1:00部署了一个包含设置的校正版本. □ 跟进 1. 设置现在是主码行的一部分,因此未来的发布包括它. 2.我们改进了警报和端到端测试套件,以赶上更早的回归.
自动翻译自官方事件更新。
在2026年10月1日协调世界时14:23至16:04之间,澳大利亚地区UiPath自动化云服务中的一些删除项目请求以"404 Not Found"出错而失败. 受影响的服务包括Orchestrator、文件理解、AI中心和数据服务。 其他业务,例如查看、创建和更新项目,正常运作。 原因是我们请求的路由改变了配置。 我们把它卷回,服务完全恢复.
□ 客户影响 在2026年10月1日 UTC下午2点23分和UTC下午4点04分之间,一群客户经历了**404 Not Found**澳大利亚地区一些UiPath自动化云请求的错误. 事件持续了1小时41分. 受影响的请求包括删除操作和一些机器人连接检查. 受影响的服务包括Orchestrator、文件理解、AI中心和数据服务。 称为"Orchestrator"的机器人工作可能失败了,客户可能需要重新运行任何在此窗口中失败的机器人工作. 所有其他行动没有受到影响。 □ 根源 路线配置的改变适用于澳大利亚地区,由于放行管道超时,整套辅助操作不全. 删除配置中缺失的操作,因此这些请求在到达基础服务前被以**404未找到**的路由层拒绝. □ 检测 自动端到端监测通过提醒注意文件了解服务检查的失败,发现了这一问题. 我们的工程小组然后利用内部监测数据,确认受影响服务中更广泛的故障模式。 □ 回应 在调查期间,监测数据显示,通过澳大利亚地区处理的请求正在退回**404号未发现**错误,而通过其他区域处理的请求没有受到影响。 分析发现,**404的起动时间没有发现**响应增加与路由配置生效的时间有关. 团队将路由配置恢复到之前的工作版本. 复出后,监测显示误差计数在约3分钟内下降,服务于2026年10月1日协调世界时下午4:04全面恢复. □ 跟进 1. 改进关于4xxx基准变化的路由层警报 2. 检测部分应用的路由配置后再生效
自动翻译自官方事件更新。
我们的团队正在积极研究如何解决影响美国地区兽医的退化表现。 随着进展,我们将分享最新情况.
目前正在为影响美国区域的Orchestrator和行动中心的退化性能部署一个固定装置。 随后将进一步提供最新情况.
已经针对影响美国地区的Orchestrator和行动中心的退化性能采取了一项措施。 我们的小组正在积极监测结果,以确认这一问题已完全解决.
已经针对影响美国地区的Orchestrator和行动中心的退化性能采取了一项措施。 我们正在继续监测系统的业绩和稳定性,以确认这一问题已完全解决。 一旦获得更多信息,将提供进一步的最新资料.
影响美国地区的Orchestrator和行动中心的退化性能已经得到解决。 系统运行在完成修复后保持稳定,我们将继续进行标准监测.
□ 客户影响 在协调世界时约11:00至2026年10月1日13:40之间,美国地区的客户观察到Orchestrator反应时间较慢并间歇性超时. 机器人需要更长的时间才能开始工作,处理队列项目并读取资产,其中一些请求失败了. 其他依赖Orchestrator的UiPath服务也在Orchestrator退化时受到影响,可能出现反应较慢或出错. □ 根源 整形仪的部署包括改变如何为我们的服务保留和扩大计算能力。 改革的目的是更有效地利用我们的基础设施,但它降低了Orchestrator的处理能力。 在繁忙的时期,我们的自动规模没有按预期增加能力,因此服务无法跟上需求。 □ 检测 我们的内部监测发现更新后放缓。 我们的第一个计划是通过我们的标准发布程序 发布一个更正的更新,这需要几个小时。 当客户报告开始进来时,我们打开了一个事件,并移动到更快的修复. □ 回应 我们的工程组将以前的能力设置直接应用于受影响的服务,而无需等待经过更正的更新。 响应时间在协调世界时13:40左右恢复正常,我们继续进行监测以确认服务是稳定的. □ 跟进 为了防止这种情况再次发生,我们: - 永久恢复以前的能力设置,并在推出之前对照生产级负荷审查今后的能力变化。 - 改进我们评估客户在退化过程中的影响的方法,从而将其升级为更早的事件。 - 在影响客户时更快地回滚能力和配置变化.
自动翻译自官方事件更新。