Orchestrator logs are not visible in the US regions

Final update

## Customer impact Between August 27, 2026 at 5:00 pm UTC and August 27, 2026 at 8:30 pm UTC, robot logs in UiPath Orchestrator were delayed and, for some customers, did not appear in the logs view as expected. The customer-facing impact lasted for approximate 3 hours and 30 minutes. A subset of customers in the US region were affected. Automation execution remained available, but customers could not reliably view recent robot log entries until ingestion caught up. Jobs continued to run normally, and all logs generated during the incident were durably retained throughout. ## Root cause Robot logs flow through a durable ingestion stream and are indexed into the search store that powers Orchestrator's log views by a dedicated indexing tier. During the incident, some indexing consumers stopped making progress: logs continued to be received and safely stored, but a portion were no longer being indexed for display. The indexing processes remained running and continued to pass automated health checks, so the platform's self-healing mechanisms did not trigger. Because the corrective restart also cleared the components' internal state, the exact trigger of the blockage could not be conclus

1. Postmortem · Sep 9, 06:33 UTC
   ## Customer impact Between August 27, 2026 at 5:00 pm UTC and August 27, 2026 at 8:30 pm UTC, robot logs in UiPath Orchestrator were delayed and, for some customers, did not appear in the logs view as expected. The customer-facing impact lasted for approximate 3 hours and 30 minutes. A subset of customers in the US region were affected. Automation execution remained available, but customers could not reliably view recent robot log entries until ingestion caught up. Jobs continued to run normally, and all logs generated during the incident were durably retained throughout. ## Root cause Robot logs flow through a durable ingestion stream and are indexed into the search store that powers Orchestrator's log views by a dedicated indexing tier. During the incident, some indexing consumers stopped making progress: logs continued to be received and safely stored, but a portion were no longer being indexed for display. The indexing processes remained running and continued to pass automated health checks, so the platform's self-healing mechanisms did not trigger. Because the corrective restart also cleared the components' internal state, the exact trigger of the blockage could not be conclusively determined from retained telemetry. The behavior is consistent with a known failure mode of the third-party component involved, in which stream consumers can silently stop consuming after a transient error without crashing. An internal data processing and transport component within the log ind
2. Resolved · Aug 27, 21:57 UTC
   The issue has been resolved and logs are populating as expected.
3. Monitoring · Aug 27, 20:31 UTC
   Logs are now populating as expected in real time and we will continue monitoring the application.
4. Identified · Aug 27, 18:53 UTC
   We identified that robot logs ingestion was delayed. Robot logs are catching up to live data and we are monitoring recovery.
5. Investigating · Aug 27, 17:16 UTC
   We are investigating reports of missing robot logs in the US region. Our teams are working to identify the cause and will share more details as the investigation progresses.