Orchestrator logs are not visible in the US regions

Update timeline

1. investigating Aug 27, 2026, 05:16 PM 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.

2. identified Aug 27, 2026, 06:53 PM UTC

   We identified that robot logs ingestion was delayed. Robot logs are catching up to live data and we are monitoring recovery.

3. monitoring Aug 27, 2026, 08:31 PM UTC

   Logs are now populating as expected in real time and we will continue monitoring the application.

4. resolved Aug 27, 2026, 09:57 PM UTC

   The issue has been resolved and logs are populating as expected.

5. postmortem Sep 09, 2026, 06:33 AM 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 indexing tier became blocked. No customer-facing component failed, and there was no performance degradation of the platform itself. The impact was limited to delayed visibility of robot logs in Orchestrator. ## Detection The issue was detected through customer reports of robot logs not displaying across tenants. The incident was declared at August 27, 2026 at 5:00 pm UTC, and the public status page was updated at 5:16 pm UTC with an initial investigation notice. No automated alerting detected the log processing stoppage — the issue was surfaced entirely through customer complaints. This represents a monitoring gap for this specific scenario that our engineering team is already working on. ## Response At 5:16 pm UTC on August 27, 2026, we posted a status update that we were investigating reports of missing robot logs in the US region. Our engineering team investigated several potential causes: the log storage cluster was confirmed healthy with all indexes intact, message queue throughput was confirmed stable, and log submission rates were normal. The investigation narrowed the issue to the log processing nodes, which had stopped ingesting data for certain groups of tenants. A restart of the affected log processing services was identified as the appropriate fix. After initial restarts showed immediate improvement, the team expanded restarts to all log processing services across the US region. By 6:53 pm UTC, all restarts were confirmed complete and the status page was updated to note that robot logs were catching up to live data. By 7:59 pm UTC, ingestion was confirmed fully up to date. At 8:30 pm UTC, the status page was updated to reflect that logs were populating in real time and the team was continuing to monitor. At 9:57 pm UTC, the incident was marked resolved. ## Follow up 1. Ingestion-lag monitoring and alerting, paging our engineering team within minutes of any indexing delay, ahead of customer-visible impact. 2. An updated rapid-mitigation runbook, so any residual manual intervention is executed within minutes. 3. Migration of the ingestion infrastructure to our next-generation deployment platform, which keeps the underlying components on current, vendor-supported versions, picking up upstream fixes and reliability improvements for the affected component.