美国劳动和社会保障部贫铀观察员的退化性能
Pending
受影响的组件
Document Understanding
- investigating
我们正在投资这个问题
- identified
会议确定了这一问题,并采取了适当的缓解措施加以解决.
- monitoring
问题已顺利解决,服务全面恢复. 该服务目前正常运行.
- resolved
问题已顺利解决,服务全面恢复. 该服务目前正常运行.
自动翻译自官方事件更新。
91 Uipath incidents · 2026年4月 — official updates, affected components, duration and resolution details.
我们正在投资这个问题
会议确定了这一问题,并采取了适当的缓解措施加以解决.
问题已顺利解决,服务全面恢复. 该服务目前正常运行.
问题已顺利解决,服务全面恢复. 该服务目前正常运行.
自动翻译自官方事件更新。
在Looker的"洞察仪表盘"中,经历了一个问题,阻止了最新的"大师跑"出现在"仪表盘"中. 受影响地区:美国、SEA、IND、CA、AUE、JP、UK 事件时间表 开始时间:2026年9月2日 UTC凌晨20:00 决议:2026年9月4日 UTC下午4:30 目前这个问题已经解决了,Insights仪表板正在显示最新的大师运行数据.
自动翻译自官方事件更新。
我们正在调查有关美国文件理解和IXP数字化和取出性能退化的报告。 影响:用户可能经历缓慢和失败的文档理解运行时间操作. 我们的小组正在努力查明原因,并将随着调查的进展分享更多细节.
我们查明了这一问题,并采取了缓解措施。 服务恢复健康,我们正在监测服务.
这个问题已经完全解决,服务现已稳定。 我们很快会把事件的更多细节张贴到状态网页上.
自动翻译自官方事件更新。
我们正在调查这个问题.
我们查明了问题,并采取了必要的补救措施
这一问题已经得到缓解,目前服务已开始运作。 我们将继续密切监测服务健康情况,并在需要时采取进一步行动.
这一问题已经得到缓解,目前服务已开始运作。 我们将继续密切监测服务健康情况,并在需要时采取进一步行动.
自动翻译自官方事件更新。
这一问题已经确定,该小组正在积极部署一个固定方案。 我们期望今后数小时内开始部署.
我们已查明造成业绩退化的根本原因,我们正在今后数小时内部署一个解决办法。 它影响用户无法访问原始文件夹的链接查询. API表面未受影响. 通过CSV输出可用作工作绕行. 随着我们走向解决,将提供更多的最新情况.
我们已查明造成业绩退化的根本原因,我们正在今后数小时内部署一个解决办法。 它影响用户无法访问原始文件夹的链接查询. API表面未受影响. 通过CSV输出可用作工作绕行. 随着我们走向解决,将提供更多的最新情况.
目前正在采用这一办法。 一旦在所有受影响地区完成部署,我们将很快提供另一个最新情况.
已在所有区域成功地实施了这一解决办法,我们已经证实这一问题已经得到解决。 该服务按预期运行.
□ 客户影响 2026年8月28日 UTC下午3点23分到2026年8月28日 UTC晚上10点57分之间,一组客户在Orchestrator打开队列项目细节面板时遇到错误. 当用户无法访问创建项目的原始文件夹时,受影响的路径返回了 LINKED 队列的404页 。 影响只影响到Orchestrator UI的交互作用,并涉及运行受影响软件版本的所有区域。 Orchestrator 应用程序编程接口的访问没有受到影响,将队列数据导出到 CSV 是一种工作。 总持续时间约为7小时。 □ 根源 事件由Orchestrator用户界面中对于从其他文件夹访问的链接队列的回归所引起. 当请求的用户无法访问原始文件夹时,回归没有正确处理链接-队列细节流,导致队列项目细节面板向404页行走,而不是显示预期信息. □ 检测 通过2026年8月28日协调世界时下午3:23为Orchestrator前端自动出事警报来检测出这个问题. □ 回应 2026年8月28日 UTC下午3点31分,我们的工程团队将这个问题描述为客户由于回归而无法访问队列项目细节面板. UTC下午3:41分,一份公开状态更新证实,已经查明了根源,正在部署一个固定装置,应用程序编程接口访问没有受到影响. 协调世界时下午5:27,范围被缩小到用户无法访问原始文件夹的链接队列. UTC下午5:29分,团队确定最初的固定没有完全解决所受影响的情景,并制定了更正后固定. 协调世界时下午5:30,重现了受影响的情景,并在当地验证了已更正的固定. UTC下午5:39,一个状态页面更新记录了CSV导出作为工作绕行. 在受影响地区继续部署经更正的固定方案。 UTC晚上10点50分,固定装置被确认部署在各地. UTC晚上10:57分,事件被标出得到解决并更新了状态页,以确认服务如期运行. □ 跟进 目前正在通过决议启动的事件后审查进程来跟踪正式的后续行动。 □ 动作项目 - 扩大我们的自动测试案例,以包括这一情景,以及与相关对象或交叉文件夹情景有关的其他类似情景。 确保我们能安全关闭任何改变 通过一面旗帜 更快的反应时间.
自动翻译自官方事件更新。
我们正在调查有关美国地区机器人日志缺失的报告。 我们的小组正在努力查明原因,并将随着调查的进展分享更多细节.
我们发现机器人的摄入被推迟了 机器人日志正在赶超实时数据 我们正在监测恢复情况.
日志现在按预期实时输入,我们将继续监测应用程序.
这个问题已经解决,日志如所预期地大量出现.
自动翻译自官方事件更新。
我们已查明一个影响日本地区Studio Web的解决方案部署功能的问题,其中解决方案部署可能失败。 一项固定措施已经制定,不久将推出。 一旦获得更多信息,我们将提供进一步的最新资料.
已成功地在日本地区部署这一固定方案,并缓解了这一问题。 我们正在密切监测这项服务,以确保“解决方案”部署继续按预期运作,并将视需要提供进一步的最新资料.
这一问题已经解决,在Studio Web的解决方案部署正在日本地区按预期运作。 没有观察到进一步的影响.
自动翻译自官方事件更新。
我们正在调查一个影响新加坡地区客户使用"透视"(Insights)的问题, 我们的小组正在努力查明根源,并将在获得更多信息后提供进一步的最新资料.
这一问题已经得到缓解,我们正在密切监测新加坡地区的Insights服务,以确保仪表板继续按预期装载.
这个问题已经解决了,新加坡地区的Insights服务正在按预期运行. 没有观察到进一步的影响.
□ 客户影响 在协调世界时2026年8月25日凌晨3:42到协调世界时2026年8月25日凌晨4:53之间,新加坡地区使用Insights的客户在装载Insights仪表板时遭遇了故障. 受影响的用户看到仪表板页面超时或无法加载,相关服务请求也观察到服务器出错. 主要影响是进入Insights仪表板,包括图表和警报。 相关的后端服务也在事故中还回了服务器出错,但仪表板访问在最终解决前已经恢复. □ 根源 该事件被归咎于新加坡的区域性微软服务中断,影响了Insights服务所使用的基础设施. 在中断期间,Insights服务无法可靠地服务于仪表板请求,导致请求超时和服务器出错. 我们方面没有作出任何改变。 服务随着微软区域干扰的解决而恢复,微软随后在其地位页面上报告了新加坡区域服务问题. 已要求微软进行正式的根源分析,以确认具体的故障机制并查明任何其他预防或缓解措施。 □ 检测 在协调世界时2026年8月25日凌晨3点42分对Insights服务进行自动健康监测检测出该问题. 检测发现后不久就确认了客户对反应桥的撞击. □ 回应 2026年8月25日 UTC凌晨3点58分,我们发布公开状态更新,指出新加坡地区的Insights仪表板可能无法加载并显示出超时出错. 在答复过程中,我们的工程组核实了服务器在自动监测方面的错误,试图访问服务诊断,并开始对基本基础设施进行恢复程序。 2026年8月25日 UTC凌晨4:01分,Insights服务在恢复程序进行时恢复了,仪表板装载通过多个测试账户验证. 2026年8月25日 UTC凌晨4点37分,我们确认仪表板成功装载后,将事件转移到了监测上. 2026年8月25日协调世界时凌晨4:49恢复了相關后端服務,并标出事件于2026年8月25日协调世界时凌晨4:53解决. □ 跟进 1. 请微软公司对影响洞察仪表板装载问题的新加坡区域干扰情况进行根源分析.
自动翻译自官方事件更新。
我们正在调查一个影响客户的问题,在新加坡地区的文件理解服务中使用扩展OCR功能。 我们的小组正在努力查明根源,并将在获得更多信息后提供进一步的最新资料.
这一问题已经得到缓解,我们正在密切监测这项服务,以确保其继续按预期运作。 一旦获得更多信息,我们将提供进一步的最新资料.
这一问题已经解决,服务正在按预期进行。 没有观察到进一步的影响.
□ 客户影响 2026年8月25日,文件通訊服務中扩展的OCR请求以500个地位代码在新加坡地区以约33分失败,在协调世界时03:08至03:41之间. 其原因是微软在新加坡的区域服务中断. 所有其他文件理解功能都未受影响,没有其他区域受到影响。 □ 根源 失败的原因是新加坡的区域性微软服务中断,影响到扩展OCR能力所使用的资源。 我们方面没有作出任何改变,微软公司随后更新了自己的地位网页,以反映新加坡的一个区域问题。 已要求微软进行正式的根源分析。 □ 检测 2026年8月25日 UTC凌晨3点13分为文件理解服务发射自动警报. 警报迅速得到确认,并在几分钟内宣布该事件对客户产生影响。 □ 回应 待命工程师将影响范围扩大到了新加坡地区。 答复者排除了作为原因的最新服务更新,因为同一更新已经部署到没有类似影响的其他区域,这表明我们基础设施以外的区域依赖性失灵。 由于故障起源于上游微软服务,UiPath方面没有采取或需要采取任何缓解行动. 协调世界时03:41,随着微软依赖恢复,请求再次成功. 响应者举行事件开放核实持续恢复:协调世界时03:51确认10分钟清运,事件于协调世界时04:04转移至Monitory,在协调世界时04:59持续稳定而无进一步故障后于协调世界时解决. □ 跟进 1. 要求微软公司对影响扩展性OCR依赖性的新加坡区域中断情况进行根源分析,包括如何防止再次发生.
自动翻译自官方事件更新。
我们已找出一个影响少数顾客的问题的原因, 我们的小组已经做好了准备,即将在受影响地区开始部署。 我们将继续监测部署情况,并随着修复措施生效提供进一步的最新情况.
已在所有受影响地区成功地实施了这一解决办法,这一问题已经得到缓解。 我们正在密切监测这项服务,以确保继续按预期进行修复,并将视需要提供进一步的最新资料.
这一问题已经解决,服务正在按预期进行。 没有观察到进一步的影响.
□ 客户影响 在协调世界时2026年8月19日下午2点33分到协调世界时11点30分的2026年8月24分之间,一子集的顾客无法从 Studio Web 上装UiPath Apps 项目. 受影响的客户完全得不到Apps项目,而不是缓慢或业绩下降。 影响仅限于一小部分客户,其Apps服务在日本地区托管. 影响客户的总时间约为4天21小时。 □ 根源 其根源是工作室Web和UiPath Apps之间的部署不匹配. 2026年8月19日,Studio Web在欧盟地区收到一个包括了框架升级的预定更新. 载有框架升级的相应UiPath Apps更新尚未部署到日本规模单位。 已经与新框架版本兼容的较早的Apps更新已经部署到了除日本以外的所有地区,日本的部署因无关原因而被推迟。 因此,日本地区仍在运行一个较老的Apps版本,与更新后的工作室Web不相容. □ 检测 2026年8月24日协调世界时9:36,一位客户通过他们的UiPath账户团队报道了这个问题. UTC上午10:21开通了一起事件,一分钟内宣布了一起公共状态页面事件. 现有的自动监测没有发现这一问题,因为它验证了匹配的部署组合;改进对混合配置的检测是我们后续计划的一部分。 □ 回应 在事件开始后的几分钟内,我们确定部署不匹配是根源,并决定加快向所有受影响地区部署相应的UiPath Apps更新,使Apps与已经提供给受影响客户的Studio Web版本保持一致. UTC上午10点43分,我们张贴了一份公开状态更新,确认已查明原因,正在部署固定装置。 协调世界时上午10:52,其余区域的部署工作正在进行,几个区域已经完成。 在协调世界时上午11点30分,我们确认已在所有受影响地区部署该固定装置,并标志着事件得到缓解。 UTC上午11点55分,在监测显示没有进一步影响后,事件被标出得到解决. □ 跟进 1. 增加生产遥测的自动警报,以检测与工作室Web版本有关的Apps负载故障。 2. 实施合成监测,在具有代表性的客户配置上定期从 Studio Web 上载一个 Apps 项目,并对故障发出警报。 3. 调整Sudio Web和Apps紧密结合的修改的发布顺序,以便在更新的Sudio Web体验到达客户流量之前,将依赖的Apps更新充分部署到所有地区.
自动翻译自官方事件更新。
已经针对影响美国文件理解文件分类和提取的问题采取了一项措施,我们正在监测结果.
影响美国地区文件分类和取出以了解文件的问题已经解决。 经过一段时间的监测,确认服务健康并正常运行.
□ 客户影响 在协调世界时2026年8月21日11:05到协调世界时2026年8月21日12:18分之间,一部分客户经历了文件了解操作失败,包括文件分类,提取,和数字化. 部分停电时间估计为48分钟。 影响仅限于使用美国地区文件谅解的客户。 □ 根源 事件由文件理解存储数据库故障配置导致,在预防性数据库扩大操作中进入了破损状态. 扩大工作是在数据库接近存储限度后开始的。 在操作过程中,二级数据库无法缩放,试图去除故障配置失败,数据库平台提供者不得不中断复制链接. 这使得故障配置处于暂时不可用状态,导致依赖于该数据库的存储和运行时间服务失败请求. □ 检测 该事件通过文件理解服务自动警报被检测出,在协调世界时2026年8月21日中午12:10被确认. □ 回应 在宣布影响客户事件之前,主要数据库的扩大工作已经完成,数据库平台提供方为次级数据库问题提供支助。 在故障后配置被打破后,我们探索了重新定位服务连接,但鉴于服务目前的配置,我们无法找到安全即时的路径来进行. 通过删除不健康的二级数据库并重建故障配置,服务得以恢复。 至2026年8月21日 UTC中午12点37分,已实施固定并正在进行监测. UTC下午1点36分,监测证实服务健康,事件得到标定解决. □ 跟进 1. 请求数据库平台提供者进行根源分析,以确定为何无法扩大二级数据库的规模,以及为何故障后配置补救需要中断复制。 2. 更早地指定并采取行动更新数据库存储提醒阈值和路径,包括75%使用率的低度警告和85%使用率的高度警告.
自动翻译自官方事件更新。
我们正在调查一个可能影响到 使用克洛德·索内特4.6 在美国地区代理商的客户的问题 我们的工程小组正在积极努力了解这一问题,并将在获得更多信息后分享进一步的最新情况.
我们缓解了这一问题。 我们的工程小组上午很活跃,并将在获得更多信息后分享进一步的最新情况.
我们缓解了这一问题。 我们的工程小组正在积极监测,并将在获得更多信息后分享进一步的最新情况.
这个问题已经得到解决.
□ 客户影响 在2026年8月19日协调世界时下午1:36到2026年8月19日协调世界时下午3:53之间,一部分客户在代理公司使用克洛德·索内特4.6时收到错误. 撞击持续了约2小时17分. 影响是美国地区使用代理人的客户。 还观察到克洛德·奥普斯 4.6和克洛德·奥普斯 4.5的出错,这些出错被用在较低的体积上. -- -- . . . □ 根源 作为计划中的基础设施迁移的一部分,我们把传送代理商模型请求的平台服务移至一个新的配置交付系统,按区域分列。 新的配置来源缺少了克洛德3个型号的路由条目——克洛德·索内特 4.6,克洛德·奥普斯 4.6,克洛德·奥普斯 4.5. 如果没有这些条目,服务就不能解决向这些模型提出的请求的有效目的地,并错误地拒绝了这些请求。 其他模型没有受到影响,而且在整个过程中继续正常使用。 -- -- . . . □ 检测 该问题于2026年8月19日协调世界时下午2点55分——在第一次受影响的请求后约1小时19分被客户升级检测出. 我们的工程组将问题范围扩大到克洛德模型 并开始调查 公众身份沟通于协调世界时下午3:08开始. 我们的警报监测基于总误差率。 虽然对这三种受影响的模式提出的几乎所有要求都失败了,但这些模式占该区域总流量的一小部分,因此,总信号没有越过我们的警戒阈值,问题没有自动提出。 这就是下文后续行动中涉及的发现差距。 -- -- . . . □ 回应 UTC下午3:25分,未完成的配置源被确定为原因,并开始修复. 协调世界时下午3:47,正在部署固定装置,随着改变的展开,服务受到积极监测。 至UTC下午3:59分,服务日志确认该问题已经得到缓解,到UTC下午4:00,故障率被确认为0%. 该事件在协调世界时下午4:40被标为缓解了,在持续监控和客户确认服务正常运行后,在协调世界时下午4:55宣布完全解析. -- -- . . . □ 跟进 所有区域的基础设施迁移已经完成,路线配置现在仅取自一个来源,消除了造成这一事件的不匹配之处,因此不再发生。 正在实行自动化检查,以不断核查每个区域中每一个得到支持的模型,因此立即发现一个无法使用的模型并发出警报,包括在交通较低的地区.
自动翻译自官方事件更新。
我们正在调查关于欧洲社区用户中Asgentic管弦乐团HITL任务输出参数的表达评价出现故障的报告。 影响:用户可能无法完成 HITL 任务 下一次更新:我们的团队正在努力了解原因和范围,并将分享现有更新.
我们已查明了欧洲社区用户Agentic Orchestration与HITL任务产出参数有关的断电影响表达评价的原因。 影响:用户在有使用HITL任务输出参数的表达式时会遇到故障. 下一次更新:我们的团队正在努力了解原因和范围,并将分享现有更新.
我们确定了解决办法,决议正在执行中。 下一次更新:我们的团队正在修补中,并将尽可能分享更新.
我们已落实了解决办法并正在监测该决议。 下一次更新:我们的小组正在监测决议,并将分享现有更新.
停电问题已经解决,代理管弦乐团全面投入使用. 影响:没有持续的用户影响.
自动翻译自官方事件更新。
我们已经在 Studio Web 中找出一个问题的根源, 其中用于改变资源属性的资源配置屏幕没有加载 。 我们正在部署一个固定.
修复工程的部署正在进行中。 我们将随着部署的进展提供进一步的最新情况.
这项工作已得到核实,并正在所有剩余地区推广。 我们正在监测部署和恢复情况。 谢谢你的耐心.
其余区域的推广工作正按预期取得进展。 我们继续监测部署情况。 谢谢你的耐心.
其余区域的推广工作正按预期取得进展。 我们继续监测部署情况。 谢谢你的耐心.
推广工作已经完成,问题应当解决.
自动翻译自官方事件更新。
我们正在调查一个影响社区账户的问题,其中新设立的实体可能需要大约一个小时才能出现在Studio Web。 没有丢失数据,现有实体没有受到影响.
我们继续调查这一问题,并正在努力查明根源并恢复正常的处理时间.
我们继续调查影响欧洲、美国和日本一分租户的问题,在那里,新成立的实体可能比预期在Studio Web出现的时间要长。 没有丢失数据,现有实体没有受到影响.
我们已查明了原因,并正在就影响到欧洲、美国和日本少数租户的问题拟订一项解决办法。 谢谢你的耐心.
这个问题已经得到缓解,我们期望处理时间很快会恢复正常。 我们正在密切监测复苏情况。 谢谢你的耐心.
问题已经解决,处理时间已经恢复正常. 谢谢你的耐心.
□ 客户影响 在协调世界时2026年8月18日5:11到协调世界时2026年8月18日11:57之间,在UiPath Cloud租户的一个子集中新创建的实体可能需要比预期在Studio Web出现的时间更长. 在进行初步评估时,新成立的实体出现的时间大约为一小时。 欧洲、美国和日本的客户受到影响。 实体创建本身继续顺利进行,没有丢失数据,现有实体未受影响。 □ 根源 造成这一问题的原因是一个租户提出了异常多的资产创造请求。 这些请求所产生的事件比我们的后端实体索引服务能够以同样的速度处理,从而造成事件处理排队的积压。 因为 Studio Web 依赖于此服务来显示新创建的实体,所以新实体只有在处理积压后才出现. □ 检测 该问题由我工程组通过实体处理延迟警报确定,2026年8月18日协调世界时凌晨5:11宣布出事. 到了协调世界时凌晨5点23分,分析证实最后一个处理的实体大约落后了一小时. □ 回应 UTC凌晨5点32分,我们发布初步客户更新,注意到Studio Web新创建的实体的能见度被延迟. 到了协调世界时6:07,调查发现一名租户异常高的资产创造流量,在协调世界时7:03,我们调整了受影响服务的数据库资源,以帮助处理恢复. UTC早上7点59分,高请求量的来源已停止发送请求,排队开始排出. UTC早上9点59分,我们为受影响的租户开始了数据同步进程,UTC早上10点31分,我们移除了有问题的排队事件,这样正常的处理可以更快地赶上. 排队深度从协调世界时8:34分的95,000个项下降到协调世界时11:44分的1,000个项. 该事件在协调世界时11:19处理后大幅恢复后被标为缓解,在协调世界时11:57处理时间恢复正常后被解决. □ 跟进 重新触发受影响的租户的数据同步,并监控摄入,直到租户的数据得到一致确认. 改进索引后端的实体处理,这样积压不会以这个速度堆积.
自动翻译自官方事件更新。
We have identified the cause of the degraded performance impacting Orchestrator in US region and are working on mitigation. Impact: Users may experience delayed loads and views on Orchestrator Robot logs. Additional updates will be provided as we move toward resolution.
The issue has been resolved and Orchestrator Robot logs performance has returned to expected levels after degraded performance impacted Robot logs to load in US region. Impact: No ongoing user impact.
## Customer impact Between August 14, 2026 at 8:54 pm UTC and August 15, 2026 at 2:09 AM UTC, a subset of customers in the US region experienced significant slowness in the Orchestrator Jobs and Logs pages, and robot logs appeared later than expected in the logs view. Performance had substantially recovered by 11:22 PM UTC on August 14, with full recovery confirmed with affected customers at 2:09 AM UTC on August 15. Automation execution was not affected, jobs continued to be scheduled and to run normally throughout. No log data was lost. Logs continued to be recorded and became visible once the system caught up. Requests did not fail, so no errors were surfaced, pages were slow to load and recent activity appeared missing or delayed. No other region was impacted. ## Root cause Orchestrator stores and retrieves robot logs using a dedicated search and storage system. Routine maintenance on that system causes data to be redistributed internally across the cluster. Our analysis indicates that a redistribution larger than anticipated consumed capacity that would otherwise have served customer requests, slowing both the retrieval of existing logs and the processing of new ones. This accounts for the majority, but not the entirety, of the slowdown observed, and analysis of the remaining contributing factor is continuing. Capacity returned to normal without intervention, at which point log visibility and page performance recovered. ## Detection The issue was surfaced through customer reports of slow Jobs and Logs pages in the US region. ## Response We posted a status update confirming that we were investigating degraded Orchestrator performance in the US region. Our engineering team scoped the impact to the US region and narrowed the slowdown to the log storage and search layer. The degradation stemmed from capacity contention that eased as the redistribution completed, and responders monitored the system through recovery. Page performance and log visibility returned to expected levels over the course of the evening, and recovery was subsequently confirmed with affected customers at 2:09 AM UTC on August 15. ## Follow up 1. We are adding monitoring and alerting on the response times customers experience and on the delay between a robot log being generated and becoming visible, so that degradation of this kind is detected proactively. 2. We are documenting an operational procedure that gives our on-call engineers defined steps to reduce customer impact during this class of degradation. 3. We are changing how routine maintenance on the log storage system is scheduled and paced in the US region so that it does not affect customer-facing performance. 4. We are increasing spare capacity in the log storage system so that internal data movement has room to complete without competing with customer requests.
在IXP Communications Mining中一个很少使用的模型特性上出现了一阵请求风暴,导致一个重试回环来锁定更广泛的IXP API中的同步请求. 这导致500's的要求失败,因为工人忙于长期的要求. 自动放大迅速达到其最大容量,而解析工作只能通过应用一个代码固定,对贡献的API请求引入了严格的超时. 请求风暴从协调世界时15:10左右开始,以自动警报探测出协调世界时15:15. 分辨率在协调世界时18:15左右得到确认. 这一事件最初被错误地归咎于只有客户制造了请求风暴,但后来被发现影响了更广泛的用户. 总的影响仅限于美国少数用户.
□ 客户影响 2026年8月12日,在协调世界时约15:10至18:15之间,美国地区通信矿业(IXP)的用户间歇性请求失败. 这一事件仅限于该区域的一个部署单位,其用户在5至10分钟的时间内发现故障,其中多达5至7%的请求在高峰时出现5xx错误而失败。 在服务正常运行期间,经反复审理的请求一般都成功,没有丢失数据。 □ 根源 根据需求计算机器学习预测的API功能很少使用,但请求的风暴恰好与重复再培训所请求的模型同时发生。 每次再培训都会使缓存预测无效,将每个请求变成多分钟的计算. API没有为请求等待这一计算需要多长时间设定时限,因此这些长期请求逐渐占用了所有请求处理能力,导致不相干的请求失败. 自动缩放迅速达到最大容量,无法补偿. □ 检测 自动监测在协调世界时15:15检测出故障,即撞击开始后约5分钟,并呼叫待命工程师。 这一事件最初只归咎于生成请求风暴的客户,但客户报告和进一步调查显示,在故障暴发期间,有更广泛的用户受到影响. □ 回应 随叫随到的工程师将失败追踪到在点播预测路径中无所限制的等待. 服务能力通过自动实例替换而多次得到恢复,同时开发了代码固定. 固定是严格暂停提交请求,因此在不影响其他请求的情况下迅速失效,在协调世界时18:00左右被部署到了受灾地区,并在协调世界时18:15确认解答. □ 跟进 1. 严格的停工和卸载固定装置已经永久化,并分发给所有地区(2026年8月13日完成)。 2. 评价每个客户对按需预测计算的限制,以便单一客户的使用不能降低共享的API.
自动翻译自官方事件更新。
我们正调查对美国东部地区前端服务的退化性能影响。 影响:用户在访问GXP US的UI时可能会注意到超时. 下一次更新:一旦获得更多信息,将提供更多更新.
这一问题已经解决,在GXP东美地区的UI业绩下降后,文件谅解前端服务的业绩已恢复到预期水平。 影响:没有持续的用户影响.
□ 客户影响 2026年8月10日13:21 UTC至2026年8月10日14:03 UTC期间,一子客户在访问提供设计时间经验的"文档理解"用户界面时,在被延迟的美国地区遭遇了性能退化和超时. 文件处理自动化没有受到影响。 □ 根源 在从文件理解用户界面后原有的服务构建到被延迟的美国地区的人工部署中,我们的部署进程将正在部署服务的版本标识符重新分配。 文件理解接口要求其辅助资源与所部署的服务在同一版本标识下提供. 由于部署过程改变了这个标识符,接口无法找到所需资源,导致无法进入或超时. □ 检测 在部署完成后,我们通过人工核查,作为人工部署清单的一部分,了解了这个问题。 不久后自动发出警报,于协调世界时2026年8月10日13:28被触发. □ 回应 在查明人工部署失败的原因后,我们的工程小组开始利用现有资源部署经更正的更新数据。 同时,行动小组也参与对部署进行人工回滚。 回滚于协调世界时14:03完成,恢复了对设计时间体验的获取. UTC下午14点11分,我们公布了一份公开状况更新,显示美国延迟地区文件理解用户界面的性能退化和可能的超时. 至协调世界时14:15,已完成已校正的更新,确认界面已部署,并有正确的新版本并有效. UTC下午14:25分,事件被标清并更新了公共状态页面,以确认"文件理解"界面性能已恢复到预期水平. □ 跟进 1. 我们正在缩短恢复先前版本服务所需的时间,以便更快地从部署失败中恢复。 2. 我们正在改进人工部署程序,以预防今后出现这种情况,方法是确认所需资源的存在是先决条件.
自动翻译自官方事件更新。
We have identified the cause of the outage impacting Uipath Apps is facing outage in Delayed US region and are working on a fix. Impact: Users may continue to be unable to access Uipath Apps and solutions dependent on Uipath Apps. Team is working on service restoration.
Team is working on service restoration. We will update the status once mitigation is completed.
Team has identified an issue with an underlying resource and is actively working to restore service.
Team has made progress to fix underlying resource issue and is actively working to restore service.
Mitigation has been applied and performance is improving for the issue. We are monitoring closely to ensure stability.
The mitigation has remained stable, and performance has returned to expected levels. We have confirmed service restoration for UiPath Apps in the Delayed US region and are marking this incident as resolved.
## Customer impact Between 11:20 am UTC and 2:54 pm UTC on August 8, 2026, a subset of customers in the Delayed US region experienced failures accessing UiPath Apps and solutions that depend on UiPath Apps. Customers may have seen UiPath Apps unavailable or intermittent request failures. The impact lasted approximately 3 hours and 34 minutes. ## Root cause The incident was caused by database connection saturation following scheduled maintenance performed by our database provider. As application services scaled up, they created additional database connections, which caused new connection attempts to fail and resulted in connection reset errors in UiPath Apps. ## Detection Automated alerts detected the issue at 11:24 am UTC on August 8, 2026. Application telemetry showed failures beginning at approximately 11:20 am UTC. ## Response At 11:00 am UTC, scheduled maintenance began automatically. At 11:20 am UTC, requests began failing. At 11:24 am UTC, automated alerts were triggered, and the team began investigating. At 12:24 pm UTC, database capacity was scaled up as a mitigation. At 1:13 pm UTC, application services were restarted to reduce saturated connection usage and refresh database connections. Connection levels remained elevated, and the database automatically scaled at 1:22 pm UTC and at 2:36 pm UTC. Following these mitigation efforts, request failures stopped at 2:54 pm UTC. At 3:33 pm UTC, the mitigation was confirmed to be stable, and performance was improving. Full recovery was confirmed at 4:01 pm UTC after performance returned to expected levels. ## Follow up 1. Obtain and review the database provider's root cause analysis explaining what caused the connection issue following their maintenance activity. 2. Implement an application-side limit on database connection creation to prevent connection saturation. 3. We are reviewing the automatic scaling behavior that amplified connection volume during the incident and address any contributing factors.
Between 06-08-2026 10:00 UTC and 06-08-2026 13:00 UTC, some organizations in the US region were unable to complete document ingestion. A small number of search requests in the same region were also slow or timed out. The issue was caused by a capacity constraint affecting ingestion processing in US. Normal performance was restored at 13:00 UTC. We have monitored the affected environments since recovery and confirm the issue is fully mitigated. Ingestion requests that failed during this window were not retried automatically and will need to be re-submitted. No action is required for search.
## Customer impact Between August 6, 2026 at 10:00 am UTC and 1:00 pm UTC, some organizations in the US region were unable to complete document ingestion in **UiPath Context Grounding**. A small number of search requests in the same region were also slow or timed out. **Action required:** please re-submit the affected ingestion requests. Ingestion retries a failing request automatically for a limited number of attempts. Once those attempts are exhausted the request is marked failed and is not retried again, so affected documents will not appear in your index until the request is submitted again. Failed requests are listed in the ingestion history for each index. No action is required for search. Those requests were affected only while the issue was ongoing, and subsequent searches completed normally. --- ## Root cause A sudden increase in concurrent document ingestion triggered a high number of simultaneous document validation steps, which created a capacity bottleneck on the underlying infrastructure resource beyond its scaling capacity. Once that resource was saturated, ingestion operations began exceeding their time limits and failing. Automatic retries of the failed operations added further load, which sustained the condition. Search requests served by the same resource were delayed behind the same contention. --- ## Detection Automated alerts were flagged as the condition developed, and an automated infrastructure resource capacity alert triggered at 10:37 am UTC brought it to the team's attention. --- ## Response - **10:03 am UTC** — Automated low severity alerts started coming in. - **10:37 am UTC** — Automated alert for resource capacity issue paged the team. - **12:23 pm UTC** — As a mitigation step the impacted resource's capacity was increased. - **12:57 pm UTC** — Ingestion and search operations stopped failing and response times returned to normal. --- ## Follow-up - **The fix is deployed.** The validation step has been reimplemented to enforce the same limits at a small fraction of the previous cost, so this level of concurrent ingestion now sits well within available capacity. It was released to the affected US region on August 7, ahead of schedule, and reaches all remaining regions by early September. - **We are improving how quickly we detect issues like this.** We are adding monitoring that tracks whether document ingestion is completing successfully for customers, so problems are identified and acted on directly rather than inferred from underlying system alerts. This will be in place across all regions by the end of August.