91 Uipath incidents · 2026年4月 — official updates, affected components, duration and resolution details.
現在、課題を調査中です
問題は特定され、適切な緩和措置がそれに対処するために実施されました.
問題は解決され、サービスは完全に復元されました。 本サービスは、本日正常に動作しています.
問題は解決され、サービスは完全に復元されました。 本サービスは、本日正常に動作しています.
公式のインシデント更新を自動翻訳しています。
Lookerのインサイトダッシュボードは、ダッシュボードに表示されることから、最新のMaestroの実行を防ぐ問題を経験しました。 影響区域:米国、海、IND、CA、AUE、JP、イギリス インシデントタイムライン 開始:2019年9月2日 20:00:00 UTC 解決する: 9月 4, 2026 に 16:30:00 UTC 問題は現在解決しており、 Insights ダッシュボードは最新の Maestro 実行データを表示します.
公式のインシデント更新を自動翻訳しています。
米国では、文書の理解とIXPのデジタイズ化と抽出に影響を及ぼす劣化性能に関するレポートを調査しています。 影響: ユーザーは、ランタイムの動作を遅くし、失敗した文書を理解している可能性があります。 当社のチームは、原因を特定し、調査が進行するにつれて詳細を共有するために働いています.
問題を特定し、緩和を適用しました。 サービスは健康状態に戻り、サービスを監視しています.
この問題は完全に解決され、サービスが安定しています。 ステータスページへのインシデントの詳細を投稿します.
公式のインシデント更新を自動翻訳しています。
現在調査中です.
問題を特定し、必要な修正を実施しました
問題は緩和され、現在サービスが運用されています。 今後もサービスの健全性をモニターし、必要に応じてさらなる行動をとります.
問題は緩和され、現在サービスが運用されています。 今後もサービスの健全性をモニターし、必要に応じてさらなる行動をとります.
公式のインシデント更新を自動翻訳しています。
問題は特定され、チームが修正の展開に積極的に取り組んでいます。 今後は展開が始まります.
劣化した性能の根本原因を特定し、今後数時間で修正をデプロイする過程にあります。 ユーザーが元のフォルダにアクセスしていないリンクされたクエリに影響を与えます。 API 表面は影響を受けません。 CSVによるエクスポートは、ワークアラウンドとして使用できます。 解決に向けて進むと、追加アップデートが提供されます.
劣化した性能の根本原因を特定し、今後数時間で修正をデプロイする過程にあります。 ユーザーが元のフォルダにアクセスしていないリンクされたクエリに影響を与えます。 API 表面は影響を受けません。 CSVによるエクスポートは、ワークアラウンドとして使用できます。 解決に向けて進むと、追加アップデートが提供されます.
修正は現在適用されます。 すべての影響を受けた地域に展開が完了したら、別のアップデートを短時間で提供します.
修正は、すべての地域で正常に展開され、問題が解決されたことを検証しました。 本サービスは想定通り運営しております.
## 顧客の影響 8 月 28, 2026 に 3:23 午後 UTC と 8 月 28, 2026 に 10:57 午後 UTC, 顧客不足分は、 Orchestrator のキュー項目の詳細パネルを開くとき. 影響を受けたパスは LINKED キューの 404 ページを返しました。 ユーザーがアイテムが作成された元のフォルダーにアクセスしなかったとき。 影響を受けたのは Orchestrator UI のインタラクションのみに影響され、影響を受けたソフトウェアバージョンを実行しているすべての領域に及ぶ影響を受けました。 Orchestratorアプリケーションプログラミングインターフェイスアクセスが影響を受けず、CSVにキューデータをエクスポートすることで、回避策として利用できます。 所要時間は約7時間です。 ## ルート原因 この事件は、他のフォルダからアクセスされたリンクされたキューのオーケストユーザーインターフェイスの回帰によって引き起こされました。 リグレッションは、ユーザーが元のフォルダへのアクセスを欠いているときに、リンクされたキューの詳細フローを正しく処理しませんでした。これにより、キュー項目の詳細パネルは、期待された情報を表示する代わりに404ページにルーティングしました。 ## 検出 2026年8月28日(水)午後3時23分にオーガニストのフロントエンドの自動インシデントアラートで問題が検出されました。 ## 応答 2026年8月28日、UTCの3時31分に渡る当社のエンジニアリングチームは、顧客が回帰のためにキューアイテムの詳細パネルにアクセスできないと述べた。 3:41 pm UTCでは、公開状態の更新は、根本原因が特定されたことを確認し、修正が展開され、そのアプリケーションプログラミングインターフェイスのアクセスが影響を受けていないことを確認しました。 午後5時27分に、ユーザが元のフォルダにアクセスしなかったキューをリンクするようにスコープが狭くなった。 午後5時29分UTCでは、初期修正が影響を受けたシナリオを完全に解決しなかったと判断し、修正された修正が開発されました。 午後5時30分に、影響を受けたシナリオが再現され、修正が現地で検証されました。 5:39PM UTCでは、ステータスページの更新がCSVエクスポートをワークアラウンドとして文書化しました。 修正された修正の展開は、影響を受けた地域を横断して継続しました。 午後10時50分にUTCで、どこからでも修正が確認されました。 10:57PM UTCでは、事故が解決し、ステータスページが更新され、サービスの動作が期待どおりに確認されました。 ## フォローアップ フォームルフォローアップアクションは、解像度で開始されたポストインシデントレビュープロセスを通じて追跡されています。 ## アクションアイテム - このシナリオ、およびリンクされたオブジェクトまたはクロスフォルダのシナリオに関連する他の同様のシナリオを含む自動テストケースを拡大します。 - フラグを使って変更を安全にオフにすることで、応答時間を短縮できます.
公式のインシデント更新を自動翻訳しています。
米国地域におけるロボットログの不足に関する報告を調査しています。 当社のチームは、原因を特定し、調査が進行するにつれて詳細を共有するために働いています.
ロボットログの摂取が遅れることが判明しました。 ロボットのログは、ライブデータをキャッチし、回復を監視しています.
ログはリアルタイムで期待どおりにポップアップし、引き続きアプリケーションを監視します.
問題は解決され、ログは期待どおりにポップアップ表示されます.
公式のインシデント更新を自動翻訳しています。
ソリューション展開が失敗する可能性がある日本地域のStudio Webのソリューション展開機能に影響を及ぼす問題を特定しました。 修正が準備され、すぐにロールアウトされます。 情報が増えるにつれて、さらなるアップデートが提供されます.
修正は日本地域で展開され、問題は緩和されています。 ソリューションの展開が期待どおりに動作し続け、必要に応じてさらなるアップデートを提供できるように、サービスを密接に監視しています.
この問題は解決され、Studio Web のソリューション展開は、日本地域で期待されているとおりです。 さらなる衝撃が観察されていない.
公式のインシデント更新を自動翻訳しています。
ダッシュボードがタイムアウトエラーをロードし、表示できないシンガポール地域のインサイトを使用して、顧客に影響を与える問題を調査しています。 当社のチームは、根本原因を特定し、より多くの情報が利用可能になるように、さらなるアップデートを提供します.
問題は緩和され、シンガポール地域のインサイトサービスを密接に監視し、ダッシュボードが期待どおりにロードし続けることを保証しています.
課題は解決され、シンガポール地域におけるインサイトサービスが期待通りに運営されています。 さらなる衝撃が観察されていない.
## 顧客の影響 8 月 25, 2026 日 3:42 日 UTC と 8 月 25, 2026 に 4:53 に UTC, 顧客を使用して Insights に シンガポール 地域 経験の失敗 洞察 ダッシュボードを読み込む. 不具合のあるユーザーは、ダッシュボードページがタイムアウトまたはロードに失敗したり、サーバーのエラーが関連するサービスリクエストのために観察されたことを見た。 プライマリインパクトは、チャートとアラートを含むインサイトダッシュボードアクセスにありました。 関連するバックエンドサービスは、インシデント中にサーバーのエラーが返されますが、ダッシュボードアクセスは最終的な解像度の前に回復しました。 ## ルート原因 インシデントは、インサイトサービスが利用するインフラに影響を及ぼすシンガポールの地方のMicrosoftサービス妨害に起因しました。 中断中、インサイトサービスはダッシュボードのリクエストを確実に配信できなかったため、タイムアウトやサーバーのエラーが発生しました。 変更は行いません。 マイクロソフトの地域の混乱が解決され、マイクロソフトはその後、そのステータスページでシンガポール地域のサービスの問題を報告した。 正式な根本原因分析は、特定の故障メカニズムを確認し、追加の予防措置または緩和措置を識別するためにMicrosoftから要請されました。 ## 検出 Insightsサービスの自動化された健康監視は、8月25日、8月25日、3:42のUTCで問題を検知しました。 検出直後に応答橋で顧客の衝撃が確認されました。 ## 応答 8 月 25, 2026 に 3:58 UTC, 我々 は Insights がシンガポール地域のダッシュボードは、タイムアウトエラーをロードし、表示に失敗するかもしれないことを示す公開ステータスの更新を投稿しました. 応答中、当社のエンジニアリングチームは、自動監視でサーバーのエラーを検証し、サービス診断にアクセスしようとし、地下インフラの回復手順を開始しました。 2026年8月25日は4:01にUTCで、回復手順が進んでいる間にインサイトサービスが回復し、ダッシュボードの読み込みは複数のテストアカウントで検証されました。 2026年8月25日(月)に4:37にUTCにて、ダッシュボードが正常に読み込まれたことを確認し、監視に事件を移しました。 関連するバックエンドサービスは、8月25日、8月25日、8月25日、8月25日、8月25日、UTCの4:53で解決しました。 ## フォローアップ 1。 シンガポールの地域破壊のためにマイクロソフトから根本的な原因分析を要求して、インサイトダッシュボードの読み込みの問題に影響を与える.
公式のインシデント更新を自動翻訳しています。
シンガポール地域における文書理解サービスの拡張 OCR 機能を使用して、顧客に影響を与える問題を調査しています。 当社のチームは、根本原因を特定し、より多くの情報が利用可能になるように、さらなるアップデートを提供します.
問題は緩和され、期待どおりに動作し続けていることを確認するためにサービスを密接に監視しています。 情報が増えるにつれて、さらなるアップデートが提供されます.
問題は解決され、サービスが期待どおり動作しています。 さらなる衝撃が観察されていない.
## 顧客の影響 2026年8月25日、シンガポール地域における500のステータスコードに失敗した文書理解サービスの拡張 OCR リクエストは、約33分の間、38.8 と 03:41 UTC. 原因は、シンガポールでマイクロソフトの地方サービス混乱でした。 他のすべての文書の理解機能は影響を受けず、他の領域は影響を受けませんでした。 ## ルート原因 拡張された OCR 機能によって使用されるリソースに影響するシンガポールの地域の Microsoft サービス妨害に起因する障害。 マイクロソフトは、今後も変化が進んでおり、その後、シンガポールの地域問題を反映したステータスページを更新しました。 マイクロソフトから正式な根本原因分析を要求しました。 ## 検出 8 月 25, 2026 日 3:13 日 UTC で発射された文書理解サービスの自動化されたアラート. アラートはすみやかに承認され、事故は数分以内に顧客の影響を宣言しました。 ## 応答 オンコールエンジニアがシンガポール地域に影響を及ぼす影響を及ぼす 回答者は、最近のサービス更新を原因として除外しました。同じアップデートは、他の地域に比類のない影響を配備したため、当社のインフラストラクチャの外部の地域の依存性障害に指摘しました。 Microsoftサービスが上流で発生した障害のため、UiPath側でミシグレーションアクションが利用できなかったり、要求されていない。 マイクロソフトの依存関係が回復したので、リクエストは再び 03:41 UTC で成功しました。 レスポンダーは、持続的な回復を検証するために、インシデントをオープンしました: クリーントラフィックの10分が 03:51 UTCで確認され、インシデントは04 UTCで監視に移動し、さらに故障することなく継続的な安定性の後、 04:59 UTCで解決しました。 ## フォローアップ 1。 再発を防ぐことができる方法を含む、拡張されたOCRの依存関係に影響を及ぼすシンガポールの地域の混乱のためにマイクロソフトからの根本的な原因の分析を要求しました.
公式のインシデント更新を自動翻訳しています。
UiPath Apps は、複数の地域での Studio Web サービスから承認された少数の顧客に影響を与える問題の原因を特定しました。 私たちのチームは、修正準備が整っており、導入は影響を受けた地域を横断する予定です。 今後も展開を監視し、修正が効くにつれて更なるアップデートを提供してまいります.
修正は、すべての影響を受けた地域に正常に展開され、問題は緩和されています。 私たちは、修正が期待どおり実行され続けることを確実にするために、サービスを密接に監視しています.
問題は解決され、サービスが期待どおり動作しています。 さらなる衝撃が観察されていない.
## 顧客の影響 2026年8月19日から2:33のUTCと8月24日、11時30分にUTCのサブセットがUiPath AppsプロジェクトをStudio Webから読み込むことができません。 欠陥のある顧客は、低さや劣化したパフォーマンスではなく、アプリのプロジェクトを完全に利用できないように経験しました。 日本国内でアプリサービスがホストされている、お客様の小さなセットに限られた影響。 顧客満足度が約4日21時間 ## ルート原因 根本的な原因は、Studio WebとUiPath Appsの展開ミスマッチでした。 2026年8月19日、Studio Webは、フレームワークのアップグレードを含むEU地域のスケジュールされた更新を受け取りました。 フレームワークのアップグレードを含む対応するUiPath Appsの更新は、まだ日本スケールユニットに展開されていない。 既に新しいフレームワークバージョンと互換性のある以前のアプリ更新は、関係ない理由で展開が進んでいた日本以外のすべての地域に展開されていました。 その結果、日本地域は、更新されたStudio Webと互換性のない古いAppsバージョンをまだ実行していました。 ## 検出 問題は、8月24日にUiPathアカウントチームを通じて、顧客によって報告されました。 UTCの10:21にインシデントがオープンし、公開ステータスページを1分以内に宣言しました。 既存の自動監視は、一致する展開の組み合わせを検証するため、問題を検出しなかった; 混合構成の検出の改善は、フォローアップ計画の一部である。 ## 応答 インシデントを開くまで、デプロイメントの不一致を根本的な原因として特定し、影響を受けたすべての地域に対応するUiPath Appsの更新の展開を加速することにしました。Studio Webバージョンとアプリを合わせると、顧客に影響を与えるようになりました。 10:43 に UTC, 原因が特定され、修正が展開されていることを確認し、公開ステータスの更新を投稿しました. 10:52 に UTC, デプロイメントは、残りの領域の進行にありました, すでにいくつかの領域が完了しました. 午前11時11時30分にUTCにて、被災された全ての地域に修正が展開され、事故が緩和されたことを確認しました。 モニタリング後11:55にUTCが影響しなくなり、事故が解決しました。 ## フォローアップ 1。 プロダクションテレメトリーで自動アラートを追加して、アプリの負荷障害がStudio Webバージョンと関連しているのを検知します。 2. 代表的な顧客構成および失敗の警告を渡るスタジオ・ウェブから承認されるAppsのプロジェクトを頻繁に荷を積む総合的な監視を実施して下さい。 3。 依存するアプリの更新が、新しい Studio Web エクスペリエンスが顧客のトラフィックに達する前に、すべての地域に完全に展開されるため、リリース シーケンスを調整します.
公式のインシデント更新を自動翻訳しています。
米国で文書の分類や文書の理解の抽出に影響を及ぼす問題の修正が実施され、現在結果の監視を行っています.
米国地域における文書の分類や文書理解の抽出に影響を及ぼす問題が解決しました。 監視の期間に続く、サービスは健康確認され、普通作動します.
## 顧客の影響 8月 21, 2026 に 11:05 UTC と 8月 21, 2026 に 12:18 午後 UTC, 顧客が失敗した文書理解操作を経験しました, 文書の分類を含みます, 抽出, およびデジタル化. 部分的な停電の推定時間は48分でした。 米国の地域での文書の理解を使って、お客様への影響は限られています。 ## ルート原因 防止データベースのスケールアップ操作中に、ストレージデータベースの障害設定が壊れた状態に入ると、インシデントが原因でした。 データベースがストレージの制限に近づいた後にスケールアップが開始されました。 操作中、二次データベースはスケールアウトできませんでした。障害構成が失敗し、データベースプラットフォームプロバイダはレプリケーションリンクを破らなければなりませんでした。 これは、一時的な利用不能状態にフェイルオーバー構成を残し、そのデータベースに依存するストレージとランタイムサービスが失敗するリクエストを処理します。 ## 検出 事故は、8月21日、UTCの12:10に承認された文書理解サービスの自動化されたアラートによって検出されました。 ## 応答 顧客対応のインシデントが宣言される前に、プライマリデータベーススケールアップが完了し、データベースプラットフォームプロバイダからのサポートが二次データベースの問題に関与しました。 不正な設定が壊れた後、サービス接続をリダイレクトするのを探索しましたが、サービスの現在の設定を与えられたため、安全かつ即時のパスを識別できませんでした。 不健康なセカンダリデータベースを削除し、障害構成を回復することにより、サービスが復元されました。 2026年8月21日(水)午後12時37分にUTCで修正が実施され、モニタリングが進んでいました。 午後1時36分にUTCでサービスが健全であることを確認し、事故が解決しました。 ## フォローアップ 1. データベース プラットフォーム プロバイダーから根本的な原因の分析をリクエストして、二次データベースがスケールアップできず、なぜ故障構成の修正が必要かを判断します。 2. データベースのストレージのアラートのしきい値とルーティングを更新するので、アラートが割り当てられ、より低い重度警告を75%使用時、85%使用時の高重度アラートなど、以前の操作を行います.
公式のインシデント更新を自動翻訳しています。
米国のエージェントのClaude Sonnet 4.6を使用して、一部の顧客に影響を及ぼす可能性がある問題を調査しています。 当社のエンジニアリングチームは、問題を積極的に理解し、より多くの情報が利用可能になると、さらなるアップデートを共有します.
課題を緩和しました。 弊社のエンジニアリングチームは、朝から積極的に対応し、さらなる更新情報を公開します.
課題を緩和しました。 当社のエンジニアリングチームは、積極的にモニタリングを行い、より多くの情報が利用できるように、さらなるアップデートを共有します.
問題は解決しました.
## 顧客の影響 8 月 19, 2026 に 1:36 午後 UTC と 8 月 19, 2026 に 3:53 午後 UTC, 顧客からのサブセットは、エージェントで Claude Sonnet 4.6 を使用してエラーを受信しました. 所要時間約2時間17分。 米国のエージェントを使って、消費者にインパクトがあった。 また、Claude Opus 4.6 と Claude Opus 4.5 のエラーが観察され、低音量で使用されます。 お問い合わせ ## 根本原因 計画されたインフラの移行の一環として、Agents のモデルリクエストを新しい設定配信システム、地域別地域にルーティングするプラットフォームサービスを展開しました。 Claude Sonnet 4.6、Claude Opus 4.6、Claude Opus 4.6、Claude Opus 4.5の3つのClaudeモデルのルーティングエントリがなくなった。 これらのエントリがなければ、サービスは、それらのモデルへのリクエストの有効な宛先を解決できず、エラーでそれらを拒否することができます。 他のモデルは、非期待で、全体的に正常に機能し続けられました。 お問い合わせ ## 検出 問題は、8月19日に顧客のエスカレーションによって検出されました, 2026 に 2:55 午後 UTC — およそ 1 時間と 19 最初の影響を受けた要求の後に分. 当社のエンジニアリングチームは、特定のクラウデモデルの問題をスコープ付け、調査を開始しました。 パブリック・ステータス・コミュニケーションは3:08 pm UTCで始まりました。 当社のアラート監視は、集計エラー率に基づいています。 影響を受けた3つのモデルに対するほぼすべての要求が失敗しましたが、これらのモデルは、地域全体のトラフィックの小さな共有を表したため、集計信号は警告のしきい値と問題が自動的に上昇しませんでした。 以下は、フォローアップに取り組む検出ギャップです。 お問い合わせ ## 応答 午後3時25分UTCでは、不完全な構成ソースが原因として識別され、修正が開始されました。 3:47PM UTCでは、修正の展開が進んでおり、変更がロールアウトされたとサービスが積極的に監視されました。 UTCの3:59までに、サービスログは問題が緩和されたことを確認し、4:00 pm UTCの故障率は0%で確認されました。 事故は4:40 pm UTCで緩和され、サービスが期待どおりに機能していた監視および顧客確認の後で4:55 pm UTCで十分に決断は宣言されました。 お問い合わせ ##フォローアップ インフラの移行は、すべての地域で完了し、ルーティング構成が単一のソースから描画され、このインシデントを引き起こしたミスマッチを削除して再発することはできません。 各地域でサポートされているすべてのモデルを継続的に検証するために自動チェックを導入されているため、利用可能なモデルが検出され、直ちに警告されます.
公式のインシデント更新を自動翻訳しています。
欧州のコミュニティユーザーにおけるAsgentic OrchestratronのHITLタスク出力パラメータに関連する表現評価に影響する停電のレポートを調査しています。 影響: ユーザーはHITL タスクを完了できません。 次の更新: 私たちのチームは、原因とスコープを理解し、利用可能なアップデートを共有するために働いています.
HITL タスクの出力パラメータに関する、欧州のコミュニティユーザーにおける有能なオーケストレーションのアウトエイジインパクト式評価の原因を特定しました。 Impact: ユーザーは、HITL タスク出力パラメータを使用して式を持っているときに失敗を経験します。 次の更新: 私たちのチームは、原因とスコープを理解し、利用可能なアップデートを共有するために働いています.
修正と解像度が進行中であることを確認しました。 次のアップデート: 私たちのチームは、修正に取り組んでおり、利用可能なアップデートを共有します.
修正をデプロイし、解像度を監視しています。 次のアップデート:当社のチームは、解像度を監視し、利用可能なアップデートを共有しています.
アウトエイジは解決され、アジスティック・オーケストレーションが完全に運用されています。 影響: 進行中のユーザーの影響無し.
公式のインシデント更新を自動翻訳しています。
リソースの属性を変更するリソース設定画面がロードされていない、Studio Webで問題の根本原因を特定しました。 修正を実装しています.
修正の展開は進行中です。 展開が進むにつれて、さらなるアップデートが提供されます.
修正は検証され、残りのすべての領域にわたってロールアウトされています。 展開や回復を監視しています。 ありがとうございます.
残りの地域に期待されるようにロールアウトが進んでいます。 今後も展開を監視してまいります。 ありがとうございます.
残りの地域に期待されるようにロールアウトが進んでいます。 今後も展開を監視してまいります。 ありがとうございます.
ロールアウトが完了し、問題は解決する必要があります.
公式のインシデント更新を自動翻訳しています。
新しく作成されたエンティティティがStudio Webに表示されるまでに約1時間かかるコミュニティアカウントに影響を及ぼす問題を調査しています。 データの紛失、既存事業の不備はありません.
今後も問題を調査し、根本原因を特定し、通常の処理時間を回復するために取り組んでまいります.
今後も、欧州、米国、日本におけるテナントのサブセットに影響を及ぼす問題を調査し、新たに作成した企業が Studio Web に表示するよりも長くかかる場合があります。 データの紛失、既存事業の不備はありません.
欧州、米国、日本におけるテナントのサブセットに影響を及ぼす問題について、原因を特定し、解決しています。 ありがとうございます.
問題は緩和され、処理時間は短時間で戻ります。 回復を密接に監視しています。 ありがとうございます.
問題は解決され、処理時間は正常に戻りました。 ありがとうございます.
## 顧客の影響 2026年8月18日(水)～5:11 am UTCと8月18日(火)、11:57 am UTCにて、UiPath Cloudテナントのサブセットに新たに作成されたエンティティティティティティは、Studio Webで表示する予定よりも時間がかかる可能性があります。 初期評価時には、約1時間遅れで新規作成されたエンティティティが出現しました。 欧州、米国、日本のお客様には影響を受けました。 エンティティティ・クリエイション自体は、データが失われず、既存のエンティティティティティ・クリエイティビティは影響を受けていませんでした。 ## ルート原因 問題は、1つのテナントからの資産処理要求の異常に高い量によって引き起こされる。 これらのリクエストは、バックエンドのエンティティティビティインデックスサービスよりも多くのイベントを同じレートで処理し、イベント処理のキューにバックログを作成します。 スタジオ・ウェブは、新しく作成されたエンティティティを表示するために、このサービスに依存しているため、バックログが処理された直後に新しいエンティティティティが現れます。 ## 検出 問題は、レイテンシーアラートを処理するエンティティティティティティティエンティティティティティクトによって当社のエンジニアリングチームによって識別され、インシデントは8月18日、UTCで5:11に宣言されました。 5:23 am UTC では、最終処理されたエンティティティティが約 1 時間遅れて確認した分析です。 ## 応答 5:32 am UTC では、スタジオ Web で新しく作成されたエンティティティティティを遅らせた初期の顧客アップデートを掲示しました。 6:07 によって UTC, 調査は、1 つのテナントから異常に高い資産処理トラフィックを識別しました, そして 7:03 で UTC, 私たちは、回復を助けるために、影響を受けるサービスのデータベースリソースを調整しました. UTC は 7:59 で、リクエストのボリュームのソースがリクエストの送信を停止し、キューが削除されました。 午前9時59分UTCでは、影響を受けたテナントのデータ同期プロセスを開始し、10時31分UTCで、問題のあるキュートイベントを削除し、通常の処理がより速く追いつくことができます。 急な深さは、8:34 am UTC から 1,000 個のアイテムから 11:44 am UTC に減少しました。 処理が大幅に回復した後、インシデントは11:19 am UTCで緩和され、処理時間が正常に戻った後に11:57 am UTCで解決しました。 ## フォローアップ テナントのデータが一貫して確認されるまで、影響を受けたテナントおよびモニターの摂取に対するリトリガーデータの同期。 インデックス化バックエンドでエンティティティティティ処理を向上するため、バックログはこのレートでは継承されません.
公式のインシデント更新を自動翻訳しています。
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コミュニケーションマイニングで稀に使用されているモデル機能に関するリクエストの嵐は、より広いIXP APIで同期リクエストをロックダウンさせるリトライループを引き起こしました。 労働者が長時間の要求で忙しかったため、500人の失敗を要求しました。 自動スケーリングアップは、コントリビュートAPIリクエストに厳密なタイムアウトを導入したコード修正を適用することで、最大容量と解像度に達しました。 15:10 UTC を約開始し、15:15 UTC を自動警報で検出しました。 解像度は18:15頃に確認されました。 インシデントは、当初はクライアントがリクエストのストームを作るだけに起因していたが、その後、より広い範囲のユーザーに影響を与えることが判明しました。 米国の利用者が有利に制限される総影響.
## 顧客の影響 2026年8月12日、米国地域における通信鉱山(IXP)利用者は、約15:10と18:15 UTCの間で、断続的な要求の失敗を経験した。 インシデントは、領域のデプロイメントユニットの1つに限定され、5〜10分のバーストで失敗したユーザーが、ピーク時に最大5〜7%のリクエストが失敗しました。 普通に動作するサービスが破裂し、一般的にはリトリートされたリクエストが成功し、データが失われたことはありません。 ## 根本原因 要求の機械学習予測を計算するまれに使用されているAPI機能への要求の嵐は、要求モデルの繰り返し再訓練と一致しました。 無効なキャッシュされた予測を再訓練し、各リクエストを複数の分計算に変えます。 API は、リクエストがこの計算を待たせる時間制限を設けていないため、これらの長期にわたるリクエストは、全てのリクエスト処理能力を上回るようになり、関連のないリクエストが失敗する可能性があります。 自動スケーリングは、最大容量に達し、補償できませんでした。 ## 検出 15:15 UTCで自動監視が失敗し、衝撃が始まった後約5分、オンコールエンジニアをページ単位しました。 インシデントは、当初、リクエストストームを生成するクライアントにのみ属性をつけていましたが、クライアントのレポートとさらなる調査では、失敗が破綻したときに、より広いユーザーのセットが影響を受けました。 ## 応答 オンコールエンジニアは、オンデマンド予測パスの未踏の待機に失敗を追跡しました。 サービスの容量はコードの修正が開発された間自動インスタンスの取り替えによって繰り返し元通り復元されました。 修正はコントリビュートリクエストの厳密なタイムアウトなので、他のリクエストに影響を与えずに高速に失敗し、影響を受ける領域に約18時UTCに展開され、解像度は18:15 UTCで確認されました。 ##フォローアップ 1. 厳密なタイムアウトおよび負荷小屋の修正はすべての地域(完了された8月13、2026)に永久的な、解放され。 2. オンデマンド予測計算で1つのクライアントの使用量が共有されたAPIを劣化させないように、クライアント毎の制限値を評価する.
公式のインシデント更新を自動翻訳しています。
GXP東米地域を横断する文書のフロントエンドサービスに影響を与える劣化した性能を調査しています。 影響: GXP US で UI にアクセスしたときにユーザはタイムアウトに気づくことがあります。 次のアップデート: 詳細は追加アップデートが配信されます.
問題は解決され、文書理解のフロントエンドサービスの性能は、GXP East US地域のUIに影響を与えた後、予想されるレベルに戻りました。 影響: 進行中のユーザーの影響無し.
## 顧客の影響 2026年8月10日、13:21 UTCと8月10日、14:03 UTCで2026年、クライアントのサブセットは、Delayed US領域で、文書理解ユーザーインターフェイスにアクセスしたときに、劣化したパフォーマンスとタイムアウトを経験しました。 文書処理の自動化は影響を受けませんでした。 ## ルート原因 文書定義のユーザーインターフェイスの背後にあるサービスの既存のビルドから遅延した米国地域への手動展開中に、展開プロセスはデプロイされたサービスのバージョン識別子を再割り当てました。 Document Understanding インターフェイスは、そのサポートリソースが、デプロイされたサービスと同じバージョンの識別子で利用可能であることを要求します。 デプロイメントプロセスは、この識別子を変更しているため、インターフェイスは必要なリソースを見つけることができませんでした。これにより、アクセス不能またはタイムアウトになります。 ## 検出 導入が終わったら、マニュアルの展開チェックリストの一部としてマニュアル検証で問題の瞬間を意識しました。 2026年8月10日に13:28 UTCでトリガーされた、自動アラートを短時間でフォローしました。 ## 応答 マニュアル展開の失敗の理由を識別した後、エンジニアリングチームは、利用可能な必要なリソースで修正された更新をデプロイし始めました。 同時に、オペレーションチームはデプロイの手動ロールバックを実行しようとしました。 ロールバックは14:03 UTCで完了し、設計時間の経験へのアクセスを回復しました。 14:11 UTCでは、遅延した米国地域のユーザーインターフェイスの文書理解における劣化したパフォーマンスと可能なタイムアウトを示す公開ステータス更新を発表しました。 14:15 UTCによって、修正された更新は完了し、インターフェイスは正しい新しいバージョンおよび働きと展開するように確認されました。 14:25 UTCでは、インシデントが解決し、公開ステータスページが更新され、文書理解インターフェイスのパフォーマンスが予想されるレベルに返されたことを確認します。 ## フォローアップ 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.