UiPath Outage History

Started Apr 19, 2026, 10:01 AM UTC· resolved Apr 19, 2026, 02:49 PM UTC

1. investigating Apr 19, 2026, 10:01 AM UTC

   Jobs running in the serverless environment in the Canada region may have experienced intermittent request failures, causing the entire job to fail.

2. identified Apr 19, 2026, 11:06 AM UTC

   We have identified the fix and it is currently being deployed.

3. identified Apr 19, 2026, 11:27 AM UTC

   We have mitigated the issue and are now applying a fix.

4. monitoring Apr 19, 2026, 01:26 PM UTC

   The issue has been mitigated, and services are functioning as expected. We are continuing to monitor the environment to confirm full recovery.

5. resolved Apr 19, 2026, 02:49 PM UTC

   The issue has been mitigated and system is stable..

Read the full incident report →

Started Apr 17, 2026, 11:10 AM UTC· resolved Apr 17, 2026, 02:28 PM UTC

1. investigating Apr 17, 2026, 11:10 AM UTC

   We have identified an issue affecting customers who have a VPN gateway configured and are navigating through the UI. Other customer scenarios remain unaffected. Based on current observations, the overall impact is low.

2. identified Apr 17, 2026, 12:14 PM UTC

   A fix has been identified and is currently being implemented.

3. monitoring Apr 17, 2026, 01:40 PM UTC

   A fix has been deployed, and we are actively monitoring the system.

4. resolved Apr 17, 2026, 02:28 PM UTC

   A fix has been deployed, and system is stable.

Read the full incident report →

Started Apr 17, 2026, 09:29 AM UTC· resolved Apr 17, 2026, 12:28 PM UTC

1. investigating Apr 17, 2026, 09:29 AM UTC

   Subset of operations across multiple services is intermittently failing across multiple regions.

2. identified Apr 17, 2026, 10:39 AM UTC

   A fix has been identified and is currently being implemented.

3. monitoring Apr 17, 2026, 10:47 AM UTC

   A fix has been deployed, and we are actively monitoring the system.

4. resolved Apr 17, 2026, 12:28 PM UTC

   A fix has been deployed, and system is stable.

Read the full incident report →

Started Apr 16, 2026, 06:32 PM UTC· resolved Apr 16, 2026, 07:39 PM UTC

1. investigating Apr 16, 2026, 06:32 PM UTC

   We are currently investigating an increase in failed requests affecting Document Understanding (DU) generative extraction capabilities in both the US and EU regions. Our team has identified the issue and is actively working on mitigation. During this time, users may experience higher error rates or incomplete responses when using generative extraction features. We will provide updates as we make progress toward full resolution.

2. monitoring Apr 16, 2026, 07:23 PM UTC

   We have observed that error rates affecting Document Understanding (DU) generative extraction in both the US and EU regions have subsided. The system is currently stable, and our team continues to monitor performance closely to ensure full reliability. We will share further updates if there are any changes.

3. resolved Apr 16, 2026, 07:39 PM UTC

   The issue affecting Document Understanding (DU) generative extraction in both the US and EU regions has been fully resolved. All systems are operating normally. We will continue to monitor to ensure ongoing stability.

4. postmortem Apr 23, 2026, 06:36 PM UTC

   ## Customer Impact Between April 16, 2026 at 17:31 UTC and April 16, 2026 at 18:32 UTC, a subset of customers in the US and EU regions experienced elevated error rates and incomplete responses when using the Document Understanding service's generative extraction features. During this period, affected users encountered server errors \(HTTP 500\) when submitting documents for automated data extraction, resulting in approximately 650 failed requests across both regions, with the US region accounting for the majority. The period of elevated errors lasted approximately one hour before subsiding. Some affected organizations experienced error rates exceeding 70% at the peak of the incident, while others saw lower but still disruptive failure rates. ## Root Cause The incident was caused by an unexpected, temporary change in the response format from our external AI model provider's embeddings related endpoint. This change broke the established interface contract between the provider and our Document Understanding service, preventing the service from correctly parsing embedding responses. Specifically, our service expected a structured response object containing a required attribute, but the provider returned an empty response \(HTTP 200 with an empty body\). This caused a parsing error when our service attempted to process the response body. Importantly, the provider's endpoint continued to return a successful HTTP status code, meaning the failure was not detectable at the network level and only surfaced during response processing within our service. The issue affected multiple unrelated organizations simultaneously across both regions and lasted approximately one hour, consistent with a temporary provider-side deployment or configuration change. ## Detection The incident was detected on April 16, 2026 at 17:44 UTC, when automated monitoring systems triggered alerts for increased counts of failed requests in the Document Understanding service's generative extraction features across both the US and EU regions. Analysis of service logs and error metrics revealed a sharp rise in server errors, with multiple organizations across both regions experiencing failures. The time between the onset of elevated error rates and detection was short, owing to real-time alerting and continuous monitoring of service health. ## Response Upon detection, the engineering team immediately convened via a dedicated call to investigate the root cause. A public status page was published at approximately 18:28 UTC informing customers that the team was investigating elevated error rates and incomplete responses in the generative extraction service across the US and EU regions. Initial efforts focused on isolating the affected regions and identifying patterns in failed requests. The team examined specific failed extraction requests, retrieved error artifacts for analysis, and compared them against successful reference cases to characterize the failure mode. Our engineering team ruled out all internal causes early in the investigation. No deployments or configuration changes had been made to our systems for approximately one week prior to the incident. The team confirmed through systematic log analysis that the failures were isolated to the embedding model endpoint, corroborating the external provider as the source of the disruption. A support ticket was filed with the provider the following day to obtain a detailed explanation of the change. Error rates began subsiding approximately one hour after onset. By 18:42 UTC, the team confirmed that the incident was no longer active, though investigation into the underlying cause continued. The public status page was updated at 19:19 UTC to reflect that error rates had returned to normal and the system was stable. The incident was declared fully resolved at 19:35 UTC, with all affected services operating normally. The status page was updated with a final resolution notice, and ongoing monitoring confirmed sustained stability. ## Follow-Up To reduce the risk of similar incidents and minimize customer impact from external dependency failures, we are implementing the following targeted improvements: 1. **Fallback and redundancy strategies:** We are evaluating and, where feasible, implementing fallback mechanisms to alternative models or providers when a contract break or provider outage is detected, reducing the duration and severity of customer impact. 2. **Improved diagnostic logging:** We are updating our systems to capture and retain raw provider responses for failed requests. This will enable faster forensic analysis during future incidents and eliminate the diagnostic gap identified during this investigation. 3. **Expanded monitoring**: We are updating our suite of alerts to cover this scenario. This will significantly reduce detection time for similar incidents. These measures build on lessons learned from this and similar past events. We are committed to delivering reliable, resilient automation services and will continue to strengthen our systems to ensure that customers experience minimal disruption, even when external dependencies change unexpectedly.

Read the full incident report →

Started Apr 16, 2026, 05:26 PM UTC· resolved Apr 16, 2026, 07:16 PM UTC

1. investigating Apr 16, 2026, 05:26 PM UTC

   We're currently seeing an issue where one IXP endpoint is displaying an incorrect validation error message for a small subset of older IXP projects following a recent change. This message is not accurate and can be safely disregarded, though it may temporarily impact parts of the IXP UI. Importantly, IXP ingestion is not affected, and no action is required from customers at this time. Our team is actively working on a hotfix, which will be deployed as soon as possible. We'll share an update once the fix is in place.

2. identified Apr 16, 2026, 06:17 PM UTC

   A hotfix is currently being rolled out to address the incorrect validation error message affecting a small subset of older IXP projects. During this time, some users may continue to briefly see the incorrect message in the IXP UI. As a reminder, this does not impact IXP ingestion, and no customer action is required. We will confirm once the rollout is complete.

3. monitoring Apr 16, 2026, 06:51 PM UTC

   A hotfix has now been successfully deployed to address the incorrect validation error message affecting a small subset of older IXP projects. We are actively monitoring to ensure stability.

4. resolved Apr 16, 2026, 07:16 PM UTC

   A hotfix has now been successfully deployed to address the incorrect validation error message affecting a small subset of older IXP projects. The issue is resolved, and we are continuing to monitor.

5. postmortem Apr 21, 2026, 07:33 PM UTC

   ## Customer Impact Between April 16, 2026 at 4:30 pm UTC and April 16, 2026 at 7:22 pm UTC, a subset of customers encountered incorrect validation error messages when accessing older projects in the IXP Communications Mining web application. Specifically, users saw erroneous error messages that did not reflect actual data issues. These messages may have caused confusion or disrupted normal workflows. Although the underlying change had been deployed across all regions, the observable impact was confined to a very small number of legacy datasets in IXP Communications Mining. Data processing and ingestion continued to function normally throughout the incident, and no customer action is required. ## Root Cause A recently deployed change introduced an error in the validation logic for one API endpoint. This change caused the system to display incorrect validation error messages, which surfaced as server errors. The root cause was a misconfiguration in the endpoint's validation rules that did not properly account for legacy project formats. Requests involving these older projects triggered false error messages in the interface. The underlying data processing and ingestion functionality remained unaffected; the issue was isolated to the error-display layer. Recovery was achieved by quickly developing and deploying a targeted hotfix to restore correct validation behavior for affected projects. ## Detection Anomalous error logging was identified at around 4:30 UTC, and reported by a customer around the same time, at which point engineers began investigating. By 5:21 pm UTC, the team confirmed that the errors were limited to legacy datasets and were manifesting as incorrect validation messages in the interface. ## Response Around 5:21 pm UTC, the team identified the issue as a validation logic misconfiguration affecting older projects, confirmed that data ingestion was unaffected, and updated the status page. The hotfix was built and rolled out globally. Full resolution was confirmed at 7:18 pm UTC, when the status page was updated to Resolved. ## Follow-up **Short-term** * Enhance testing to automatically test for behaviour of legacy IXP projects * Enforce consistent serialisation logic across codebase in standard pattern to avoid unexpected edge cases, with focus on testing we can serialise legacy data models that predate later validation requirements

Read the full incident report →

Started Apr 15, 2026, 09:24 AM UTC· resolved Apr 15, 2026, 09:48 AM UTC

1. investigating Apr 15, 2026, 09:24 AM UTC

   We are currently investigating auth issues in the Europe region causing failures across multiple services .Our engineering team has identified the root cause and are in process of restoring full functionality.

2. investigating Apr 15, 2026, 09:30 AM UTC

   We are currently investigating auth issues in the Europe region causing failures across multiple services .Our engineering team has identified the root cause and are in process of restoring full functionality.

3. monitoring Apr 15, 2026, 09:39 AM UTC

   Our engineering team has implemented a fix and services are currently stabilising . We are monitoring the system to ensure stability and full recovery. Further updates will be shared soon

4. resolved Apr 15, 2026, 09:48 AM UTC

   The issue has been resolved. The system has remained stable during the monitoring period.

5. postmortem May 28, 2026, 06:23 PM UTC

   ### Customer Impact On April 15, 2026, between 8:39 am UTC and 9:07 am UTC, a subset of customers in the Europe region experienced intermittent failures when accessing UiPath services. During this period, customers may have encountered "503 Service Unavailable" and "500 Internal Server Error" messages when attempting to sign in, authenticate, or perform actions requiring identity verification. The disruptions occurred across two distinct intervals: 8:39–8:47 am UTC \(approximately 8 minutes\) and 9:00–9:07 am UTC \(approximately 7 minutes\), totaling roughly 15 minutes of active impact. Affected workflows included authentication, authorization, session management, and any automation or orchestration processes that depend on identity verification. All other regions were unaffected. No data loss occurred. ### Root Cause The incident was triggered by a sudden, large surge in authentication traffic in the Europe region. At 8:39 am UTC, request volume increased approximately five-fold within seconds, driven by legitimate customer traffic. This traffic surge caused elevated memory pressure on identity service instances, which disrupted the service's connection to its distributed caching layer. When the cache layer became unavailable due to the service's protective circuit breaker activating, all requests fell through to the underlying database. The resulting surge in database queries overwhelmed the database's concurrent request capacity within seconds, causing the identity service to return 500 and 503 errors across all API endpoints. ### Detection Our automated monitoring systems detected elevated error rates within 5 minutes of the first customer-facing errors at 8:39 am UTC. The incident was formally declared at 9:05 am UTC during the second impact window, at which point our engineering and site reliability teams were already investigating. Our public status page was updated at 9:27 am UTC to reflect the ongoing investigation. ### Response Upon formal incident declaration at 9:05 am UTC, our engineering and site reliability teams launched a coordinated investigation. By 9:08 am UTC—three minutes after engagement—the team identified the overloaded database and confirmed that its concurrent request capacity had been reached through error log analysis. The second impact window had already self-resolved by 9:07 am UTC. As an additional preventive measure, the team increased resources for the affected database at 9:16 am UTC, ensuring that even under cache-fallback conditions, the database could absorb elevated query volume without reaching its capacity limit. The team continued monitoring and confirmed sustained recovery at 9:39 am UTC. The public status page was updated to "Monitoring" at 9:41 am UTC and "Resolved" at 9:49 am UTC. No further recurrence was observed. ### Follow-Up To prevent similar incidents in the future, we are implementing several targeted improvements: 1. **Cache resilience improvements.** We are improving caching policies to be more resilient under load. 2. **Enhanced rate-limiting.** We are improving rate-limiting controls to prevent such traffic spikes from causing service unavailability. 3. **Improved scaling policies.** We are revising the auto-scaling configuration to ensure that scaling decisions account for downstream resource capacity, preventing new instances from compounding database saturation during a fallback scenario. These actions reflect our commitment to continuous improvement and reliable service delivery. We take incidents like this seriously and will continue to invest in the resilience of our platform.

Read the full incident report →

Started Apr 15, 2026, 07:37 AM UTC· resolved Apr 15, 2026, 07:48 AM UTC

1. investigating Apr 15, 2026, 07:37 AM UTC

   We are currently investigating an issue where customers in the Europe region are unable to create new Integration Service Connections. Existing connections are not impacted. Our engineering team is actively working to identify the root cause and restore full functionality.

2. resolved Apr 15, 2026, 07:48 AM UTC

   The issue has been resolved. The system is stable.

3. postmortem Apr 29, 2026, 08:49 AM UTC

   ## Customer Impact Between April 15, 2026 at 7:00 am UTC and April 15, 2026 at 7:50 am UTC, customers in the Europe region were unable to create new connections using the Integration Service. Existing connections and all other regions remained fully operational throughout the incident. Customers who attempted to create new connections received error messages. A public status page update was published at 7:40 am UTC to keep affected customers informed. ### Scope Only customers in the Europe region who attempted to create new Integration Service connections during this window were affected. All other regions and existing connections continued to function normally. ## Root Cause A recent backend configuration update to the Integration Service in the Europe region required corresponding database schema updates to be applied as part of the same deployment. Due to a conditional check in the deployment pipeline—introduced by an earlier, unrelated change—the schema migration step was skipped during rollout. As a result, the service ran against a schema that did not match the expected configuration, causing new connection creation requests to fail with internal errors. Existing connections were unaffected because they did not rely on the updated schema paths. Once the team identified the mismatch, the deployment was rolled back, which restored the service to its previous working state and normal operation resumed. Analysis of service logs and error patterns confirmed the root cause, with failures aligning precisely to the timing and scope of the deployment. ## Detection Automated monitoring detected the incident at 7:24 am UTC when error rates for new connection attempts in the Europe region exceeded normal thresholds. The alert was acknowledged within one minute, and incident response procedures began immediately. By 7:25 am UTC, the responsible team had assembled and initiated their investigation. The interval between the onset of customer impact and detection was under a minute, enabling a rapid response. ## Response At 7:05 am UTC, engineers received the automated alert and joined the incident response call to investigate error logs and recent deployments to the Integration Service. By 7:15 am UTC, the team had scoped the issue to new connection attempts in the Europe region and identified the recent deployment as the likely cause. At 7:33 am UTC, the incident was formally classified as customer-impacting. At 7:40 am UTC, a public status page update was published. By 7:48 am UTC, the team had confirmed the root cause, rolled back the deployment, and verified that new connection creation had returned to normal. Monitoring confirmed full recovery by 7:51 am UTC, and the incident was declared resolved. ## Follow-up To prevent similar incidents, we are implementing the following improvements: * **Deployment pipeline fix:** Correcting the pipeline condition that caused the database schema migration step to be skipped, and adding guardrails to ensure required schema updates are always applied alongside the corresponding service changes. * **Pre-deployment validation:** Adding automated pre-deployment checks that verify service and schema compatibility, so mismatches are caught before any customer-facing rollout. * **Canary traffic coverage:** We are adding automated test calls that exercise the new connection API against canary instances on every deployment, so schema or configuration mismatches are caught in the canary phase regardless of live traffic levels. * **Enhanced connection monitoring:** Expanding monitoring to include targeted alerts for failed new-connection attempts, enabling even faster detection of issues affecting new connections. We are also reviewing recent changes to our deployment and validation processes to identify additional safeguards. We sincerely appreciate your patience and understanding as we continue to work to make our services more resilient and dependable.

Read the full incident report →

Started Apr 14, 2026, 11:22 AM UTC· resolved Apr 14, 2026, 11:22 AM UTC

1. resolved Apr 14, 2026, 11:22 AM UTC

   We observed failures in starting jobs that rely on serverless runtimes across multiple regions. As a result, job executions on serverless runtimes were impacted. The fix has been implemented and is stable.

2. postmortem Apr 16, 2026, 12:52 PM UTC

   ## **Customer Impact** Between April 14, 2026 at 10:02 am UTC and April 14, 2026 at 11:05 am UTC, a significant number of customers were unable to start jobs that relied on Serverless runtimes. During this period, attempts to initiate Serverless jobs—including scheduled executions, debug sessions, and automation app executions—failed with errors, resulting in automation workflows not running as expected. Customers may have seen error messages \(such as conflict errors on job start requests\) or found debug functionality unavailable within their automation environments. This incident affected customers across regions globally using Serverless automation features in our cloud platform. The primary disruption lasted approximately one hour and three minutes. Some customers may have experienced brief residual effects on debug functionality in our web-based design tools shortly after the main issue was resolved. ## **Root Cause** The incident was triggered by an erroneous update to a configuration setting that controls the availability of Serverless runtimes. The intent behind the change was to disable Serverless and related compute functionality in a specific environment where those services are not deployed. However, an incorrect configuration that contained a negation clause was used. Because this negation clause was not removed, the resulting configuration inverted the intended logic—disabling Serverless runtimes across nearly all regions instead of only in the targeted environment. As a result, all requests to start jobs that depended on Serverless runtimes were rejected by the platform, returning error responses. This affected serverless workloads, debug jobs, standard automation jobs, and app executions. The misconfiguration propagated rapidly across all affected regions, as our platform services automatically refresh their configuration settings at frequent intervals. Once the error was identified through a review of the recent configuration change, the negation clause was removed and the corrected configuration was redeployed. Our platform services picked up the fix within their regular refresh cycle, restoring Serverless job execution capability across all regions. Full recovery was confirmed shortly after the corrected configuration was deployed. ## **Detection** Initial automated alerts were generated at 10:06 UTC. However, the correlation of these alerts to a customer-impacting issue was delayed due to a high volume of concurrent alert activity. The engineering team confirmed the impact and began an active investigation at 10:50 UTC. ## **Response** Upon engagement at 10:50 am UTC, engineers began investigating the root cause. By 10:54 am UTC, the team had identified a recent configuration change as a likely cause. The configuration was reviewed on an incident response call, and the erroneous negation clause was confirmed as the source of the problem—it had inverted the intended logic, disabling Serverless runtimes globally rather than in a single targeted environment. At 10:56 am UTC, a corrective update to the configuration was prepared. By approximately 10:59 am UTC, the fix was deployed. Our platform services, which automatically refresh configuration settings every ten seconds, began picking up the corrected setting shortly thereafter. By approximately 11:03 am UTC, the team observed successful job start responses from the platform, confirming that mitigation was taking effect. By 11:05 am UTC, monitoring confirmed that Serverless job execution had been fully restored across all regions, and customers were once again able to start jobs as expected. Throughout the response, the team verified recovery through both service metrics and direct testing of job execution. A status page update and impact summary were also prepared for affected customers. ## **Follow-up** To prevent similar incidents in the future, we are implementing several targeted improvements: 1. **Remove capability to disable service via Feature Flag**: We are removing the possibility to disable a service by a simple feature flag and will rely on a static service configuration that follows our Secure Deployment Principles through ringed rollouts. 2. **Stronger review and governance processes**: We are improving documentation, peer review requirements, and governance controls for configuration changes that affect service availability, ensuring that changes with broad impact receive appropriate scrutiny before deployment. 3. **Faster detection through improved monitoring**: We are enhancing monitoring and alerting to detect abnormal drops in job execution success rates within minutes, reducing detection time for service-impacting issues. This includes reviewing how existing health checks interact with traffic-based alerting to eliminate blind spots that delayed detection in this incident. We understand how disruptive this incident was to your automation workflows, and we sincerely apologize for the impact. These improvements are already underway, and we are committed to learning from this event. We will continue to invest in the reliability and resilience of our platform to better support your business.

Read the full incident report →

Started Apr 13, 2026, 06:09 PM UTC· resolved Apr 13, 2026, 11:23 PM UTC

1. investigating Apr 13, 2026, 06:09 PM UTC

   We are investigating reports of delayed data impacting orchestration tables for Insights in the United States. Our teams are actively working to identify the root cause and will share updates as more information becomes available.

2. investigating Apr 13, 2026, 07:16 PM UTC

   We are continuing to investigate reports of delayed data impacting orchestration tables for Insights in the United States. Our teams remain actively engaged in identifying the root cause. We will provide further updates as more information becomes available.

3. identified Apr 13, 2026, 08:16 PM UTC

   We have identified the issue and are currently rolling out a fix. Our teams remain actively engaged, and we will provide further updates as more information becomes available.

4. identified Apr 13, 2026, 09:24 PM UTC

   We have identified the issue and are currently rolling out a fix. Our teams remain actively engaged, and we will provide further updates as more information becomes available.

5. identified Apr 13, 2026, 10:36 PM UTC

   We have identified the issue and are continuing to roll out a fix. Our teams remain actively engaged, and we will provide further updates as more information becomes available.

6. resolved Apr 13, 2026, 11:23 PM UTC

   The issue has been identified and resolved. Data delays impacting orchestration tables for Insights in the United States have been addressed. Our teams will continue to monitor to ensure stability. Thank you for your patience.

Read the full incident report →

Started Apr 10, 2026, 12:30 PM UTC· resolved Apr 10, 2026, 12:30 PM UTC

1. resolved Apr 13, 2026, 06:31 PM UTC

   At approximately 12:30 UTC on April 10th, a change was deployed that caused a subset of EWS integrations to gradually degrade over time. The impact was not immediate and varied across integrations. At around 17:00 UTC, we detected degraded Exchange performance and began investigating. A hotfix was developed and deployed over the following hours. Full service was restored by approximately 20:30 UTC on April 10th.

Read the full incident report →

Started Apr 09, 2026, 08:12 AM UTC· resolved Apr 09, 2026, 09:15 AM UTC

1. investigating Apr 09, 2026, 08:12 AM UTC

   We are currently investigating this issue.

2. monitoring Apr 09, 2026, 08:53 AM UTC

   Services have recovered and are currently stable. We are continuing to monitor while investigating the root cause and implementing a long-term fix. Thank you for your patience.

3. resolved Apr 09, 2026, 09:15 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Apr 08, 2026, 08:36 AM UTC· resolved Apr 08, 2026, 10:49 AM UTC

1. investigating Apr 08, 2026, 08:36 AM UTC

   We are investigating the issue.

2. identified Apr 08, 2026, 09:32 AM UTC

   We have identified the issue, and a fix is currently being implemented.

3. monitoring Apr 08, 2026, 10:15 AM UTC

   A fix has been deployed and we are actively monitoring to confirm the issue is fully resolved.

4. resolved Apr 08, 2026, 10:49 AM UTC

   Monitoring has confirmed stable behavior and the issue is now fully resolved.

Read the full incident report →

Started Apr 04, 2026, 01:26 AM UTC· resolved Apr 04, 2026, 01:26 AM UTC

1. resolved Apr 04, 2026, 01:26 AM UTC

   Between 12:00 AM and 12:45 AM UTC on April 4, 2026, a database outage in north Europe region caused an interruption to trace and audit ingestion. Data ingestion might have impacted for services using LLMOps: Telemetry trace ingestion might have failed LLM inputs and outputs were not recorded in audit logs during the outage. Currently service has been restored and healthy. No Ingestion issues observed.

2. postmortem May 06, 2026, 07:08 PM UTC

   ### **Customer Impact** Between April 4, 2026 at 1:00 am UTC and April 4, 2026 at 1:45 am UTC, a subset of customers in the Europe region experienced transient failures and latency in trace and audit data ingestion for LLM products. During this 45-minute window, affected customers were unable to save LLM call inputs and outputs. The impact was limited to customers in the Europe region relying on trace and audit logging for large language model operations. Other regions and services were not affected. ### **Root Cause** A scheduled maintenance job caused an increase in DB workers percentage. Due to this sudden increase in DB workers, the database became unreachable for ingesting spans and audits. ### **Detection** Automated monitoring detected the issue at 12:56 am UTC on April 4, 2026—approximately four minutes before the start of the customer impact window. A critical alert fired when database worker utilization exceeded its threshold, and our engineering team acknowledged the alert within one minute. A coordinated response effort was immediately established. ### **Response** Upon receiving the alert, our engineering team began investigating within one minute. The team quickly determined that the trace and audit ingestion failures coincided with a recent scheduled maintenance activity. We could also see an increase in database worker utilization. The maintenance job was terminated and the database was bumped to 8 vcores, hence allowing the DB workers to restore and the ingestion to be restored ### **Follow-up** We sincerely apologize for the disruption during this window. To prevent recurrence, we are implementing the following improvements: - * **Stricter maintenance procedures:** We are updating our maintenance procedures to run in low-traffic periods and with increased resources.

Read the full incident report →

Started Apr 02, 2026, 09:47 PM UTC· resolved Apr 03, 2026, 01:23 AM UTC

1. investigating Apr 02, 2026, 09:47 PM UTC

   We are investigating customer reports of errors with Action Center

2. identified Apr 02, 2026, 10:34 PM UTC

   Our team has identified the issue and is rolling out a fix.

3. identified Apr 02, 2026, 11:53 PM UTC

   we are still working to ensure that fix is being rolled out to all regions while also testing the fix to see if its working as expected.

4. resolved Apr 03, 2026, 01:23 AM UTC

   On further investigation figured out the issue was related to automation ops outage earlier and that issue is now resolved. Singing out and Sign in again should work for customers.

Read the full incident report →

Started Apr 02, 2026, 07:11 PM UTC· resolved Apr 02, 2026, 08:33 PM UTC

1. investigating Apr 02, 2026, 07:11 PM UTC

   AO-Governance in EUS region is experiencing elevated error rates. Our team is currently investigating

2. monitoring Apr 02, 2026, 07:53 PM UTC

   From approximately 11:00 AM to 12:30 PM PST, the governance service's East US experienced resource exhaustion, UiPath generative AI services may have encountered errors during this time. Our team has scaled resources as a mitigation and investigation is ongoing.

3. resolved Apr 02, 2026, 08:33 PM UTC

   This incident is mitigated.

4. postmortem Apr 09, 2026, 06:20 PM UTC

   ## Customer Impact Between April 2, 2026, 18:01 UTC and 19:19 UTC \(approximately 78 minutes\), customers in the US region may have experienced intermittent errors and increased latency when using AI and automation services dependent on governance policy evaluations. ## Root Cause At 18:00 UTC, a scheduled batch job initiated policy evaluations across multiple organizations, generating three times the normal request volume. This sudden surge placed heavy pressure on the governance database. Consequently, services waiting for database responses timed out and automatically retried their requests. Because the original queries were still consuming database resources \(CPU and I/O\) in the background, these immediate retries created an amplification loop that ultimately led to database resource exhaustion. ## Detection Automated monitoring detected the increased error rates within the governance service and immediately alerted our engineering team, who began investigating right away. ## Response Telemetry analysis confirmed database resource exhaustion as the root cause. To mitigate the issue and break the retry amplification loop, the engineering team immediately doubled the database's processing capacity. Following this action, error rates quickly subsided, and the governance service resumed normal processing. ## Follow-Up To prevent this issue from recurring, our engineering teams are prioritizing the following actions: * **Implement Caching:** Introduce caching mechanisms for repeated governance policy lookups to significantly reduce database load during high-volume evaluations. * **Upgrade Infrastructure:** Migrate the database to an elastically scalable model to dynamically handle sudden spikes in traffic, replacing fixed capacity ceilings. * **Enhance System Resilience:** Implement intelligent retry backoff intervals and "circuit breakers" on calling services to prevent future retry amplification loops.

Read the full incident report →

Started Apr 02, 2026, 07:07 PM UTC· resolved Apr 02, 2026, 07:42 PM UTC

1. investigating Apr 02, 2026, 07:07 PM UTC

   Some customers will start seeing their conversations degraded in US EU and Singapore regions. We are currently investigating the issue.

2. investigating Apr 02, 2026, 07:08 PM UTC

   Some customers will start seeing their conversations degraded in US EU and Singapore regions. We are currently investigating the issue.

3. monitoring Apr 02, 2026, 07:41 PM UTC

   We have identified the issue to be coming from downstream services. we have mitigated the issue with downstream service and currently monitoring.

4. resolved Apr 02, 2026, 07:42 PM UTC

   Issue is now resolved.

Read the full incident report →

Started Mar 31, 2026, 08:42 AM UTC· resolved Mar 31, 2026, 10:09 AM UTC

1. investigating Mar 31, 2026, 08:42 AM UTC

   We are currently experiencing an outage affecting UiPath Data Service across multiple regions. Our engineering team is actively investigating the root cause and working to restore full functionality as quickly as possible.

2. monitoring Mar 31, 2026, 09:03 AM UTC

   Team has rolled out the fix and currently monitoring the service health.

3. resolved Mar 31, 2026, 10:09 AM UTC

   The issue is fixed and service is healthy.

4. postmortem Apr 02, 2026, 08:11 AM UTC

   # Customer Impact On March 31st 2026, 4:50 AM to 8:50 AM UTC, a small subset of customers experienced HTTP 500 errors when using the Data Service Entity Query API in multiple regions. The issue occurred only for requests containing a user-defined filter configuration when the API is used directly, distinguishing it from filters generated by platform consumption surfaces \(e.g., Activities\). For affected customers, queries with this specific payload request failed, while all other requests continued to function normally. No data loss or data inconsistency occurred. # Root Cause ‌ The issue was triggered for a subset of requests with a specific payload pattern \("filterGroups": \[null\]\) that was valid but not handled correctly by the system. A recently introduced logging component did not properly handle this input. As a result, it failed during processing and caused the API to return an HTTP 500 error. This exposed a gap in how the system handles certain uncommon but valid inputs. Additionally, because this logging runs as part of the request flow, its failure impacted the overall request instead of being isolated. # Detection ‌ The issue was initially identified through an automated Sev2 alert and was also reported by a customer. During the investigation, the engineering team identified a common payload pattern across failing requests and traced the issue to the query analytics telemetry path. # Response ‌ Upon detection, the team identified the affected execution path and applied mitigation by disabling the related functionality via a configuration change. This action immediately stopped the errors and restored normal API behavior. The issue was mitigated within 30 minutes. # Follow-Up ‌ The following actions are being taken to prevent a recurrence: * Add safeguards to ensure logging code paths do not affect request execution * Aligning and tightening the Document to have the right payloads; then add API-level validation to reject semantically invalid filter structures with 4xx responses. * Add a test case to validate this exact failing scenario is now handled correctly

Read the full incident report →

Started Mar 30, 2026, 10:12 AM UTC· resolved Mar 30, 2026, 06:26 PM UTC

1. investigating Mar 30, 2026, 10:12 AM UTC

   Uipath Agents that are newly deployed in Canada, Japan and USA will not start unless a serverless machine template is assigned to the folder. We are working on a fix, but in the meanwhile customers can manually mitigate this issue by adding a serverless machine template to the folder.

2. identified Mar 30, 2026, 11:36 AM UTC

   Team is working on a fix deployment, but in the meanwhile customers can manually mitigate this issue by adding a serverless machine template to the folder.

3. identified Mar 30, 2026, 01:34 PM UTC

   Team is making progress on a fix deployment, but in the meanwhile customers can manually mitigate this issue by adding a serverless machine template to the folder.

4. resolved Mar 30, 2026, 06:26 PM UTC

   Issue is now resolved.

5. postmortem Apr 01, 2026, 03:49 PM UTC

   # Customer impact We understand that this incident disrupted your ability to deploy new agents, and we apologize for the impact on your operations. Between March 25, 2026 at 6:21 am UTC and March 30, 2026 at 6:00 pm UTC—a period of approximately five days—customers in the EU, US, and Asia regions were unable to deploy new agents in certain folders following a transition to the Serverless Machine Runtime. Existing agents continued to operate normally throughout the incident. If you attempted to deploy a new agent in a folder without a Serverless Machine Runtime provisioned, you encountered errors and were unable to proceed. A workaround was available throughout: you could manually provision a Serverless Machine Runtime at the folder level to immediately unblock new deployments. For organizations where enabling the Serverless Machine Runtime was not viable, our engineering team restored the previous runtime configuration to resume your operations. ## Root cause A recent change transitioned newly deployed agents to run on the Serverless Machine Runtime instead of the previous runtime. This introduced a requirement for a Serverless Machine Runtime to be provisioned at the folder level before new agents could execute. This requirement was not intended. The system already contained fallback logic for other workloads—such as API Workflows—that would automatically locate or provision a Serverless Machine Runtime when one was not explicitly assigned at the folder level. However, this fallback logic was not applied to agents during the transition, creating a gap in the expected behavior. As a result, any folder without an explicitly provisioned Serverless Machine Runtime could not run newly deployed agents. Existing agents and folders with templates already assigned remained unaffected because they continued to use their previously configured runtime. ## Detection The issue was first reported by a customer on March 25, 2026 at 6:21 am UTC. Our engineering team was engaged the following day and identified the root cause, approximately one day after the initial report. We recognize the gap between the issue first surfacing on March 25 and the formal incident declaration approximately five days later on March 30, 2026 at approximately 10:00 am UTC as an area for improvement. While the workaround was communicated during this period, we should have notified you through our status page sooner to ensure you had the information needed to make decisions about your environment. ## Response Following the initial reports on March 25, our engineering team provided workarounds to affected customers. For those of you who were unable to provision Serverless Machine Runtimes, our engineering team restored the previous runtime configuration to resume your operations. Our engineering team identified the root cause and developed a fix on March 26, 2026, then validated it in a testing environment by March 27, 2026. On March 30, 2026 at approximately 10:00 am UTC, we declared a formal incident to coordinate the deployment of the fix across all affected regions. The fix ensures that if no Serverless Machine Runtime is found at the folder level, one is automatically selected from the tenant level or provisioned if none exists. We deployed the fix progressively, validated it at each stage, and provided status updates throughout the day. We achieved full recovery by March 30, 2026 at 6:00 pm UTC, when new agent deployments resumed normal operation across all regions without manual intervention. ## Follow up To prevent similar issues in the future, we are expanding our regression testing to validate that new releases properly account for all configuration, deployment, and licensing scenarios—including cases where optional infrastructure components have not been explicitly provisioned at the folder level. We are adding automated test cases that specifically verify fallback behavior across all workload types whenever runtime requirements change, ensuring that agents, API Workflows, and other workloads are validated consistently before any release reaches your environment. We are also enhancing our monitoring and alerting systems to detect deployment failures of this nature proactively, without relying on customer reports. This includes automated checks that verify new agent deployments succeed across a representative sample of folder configurations immediately after each release, allowing us to identify and resolve issues before they affect you. Finally, we are reviewing our escalation and communication processes to ensure that when issues are identified, you are notified promptly through our status page. Closing the gap between issue detection and customer communication is a priority so that you have the information you need to take action as quickly as possible. These improvements directly address the gaps this incident exposed—in testing coverage, proactive detection, and customer communication—and will help ensure that future runtime transitions do not disrupt your agent deployments.

Read the full incident report →

Started Mar 25, 2026, 06:27 PM UTC· resolved Mar 26, 2026, 03:45 AM UTC

1. investigating Mar 25, 2026, 06:27 PM UTC

   Agent Builder might not load for some customers. Impact is seen in multiple regions. The current workaround is to disable cache in the browser and refresh the page, while we are investigating the root cause.

2. identified Mar 25, 2026, 06:41 PM UTC

   We are actively working on a fix to ensure the cache is properly invalidated upon deployment. We'll share another update once the fix is ready to ship.

3. identified Mar 25, 2026, 08:07 PM UTC

   We are testing the fix and will share another update once the fix is ready to ship.

4. resolved Mar 26, 2026, 03:45 AM UTC

   The issue has been resolved.

5. postmortem Mar 27, 2026, 08:20 PM UTC

   ## Customer Impact Following a deployment, some customers experienced issues where the **Agent Builder frontend failed to load**. * **8 organizations** encountered the issue multiple times * **65 organizations** experienced the issue exactly once The issue was self-resolving upon clearing browser cache and refreshing the page. No further occurrences were observed after mitigation, and the status page was updated and resolved. ## Root Cause The incident was caused by **browser caching of a stale remote entry file** \(remoteEntry.js\) following a deployment. After the deployment, the remote entry file was updated on the server, but browsers continued to serve the previously cached version. The stale cached file referenced assets that no longer existed on the server, resulting in **404 errors** when the browser attempted to load them, causing the Agent Builder frontend to fail to load. The cache was not properly invalidated upon deployment, meaning the problem only appeared immediately after a deployment and resolved itself as browser caches expired. ## Detection The issue was **reported by a customer**. The failed requests returned 404 status codes, which **did not trigger any existing alerts** on our side. This represents a monitoring gap: 404 errors on frontend asset requests were not covered by our alerting rules, meaning the issue went undetected until a customer reported it. ## Response Upon detection: 1. **The engineering team identified the root cause** as stale browser caching of the remoteEntry.js file after the deployment. 2. **Immediate mitigation** was communicated: affected customers could resolve the issue by disabling cache and refreshing the page. 3. **Deployments were paused** to prevent further occurrences until a fix was merged into the release branch. 4. **The status page was updated and resolved** once the root cause was confirmed and mitigation verified. ## Follow-Up To prevent similar incidents in the future, we are taking the following steps: * **Deployment process improvement**: Ensuring that future deployments properly invalidate cached frontend assets to prevent stale file references.

Read the full incident report →

Started Mar 25, 2026, 05:23 PM UTC· resolved Mar 25, 2026, 06:11 PM UTC

1. investigating Mar 25, 2026, 05:23 PM UTC

   We are currently investigating an issue affecting the creation of Integration Service connections. Further updates will be provided shortly.

2. investigating Mar 25, 2026, 05:33 PM UTC

   Users are unable to create Integration Service connections in US region

3. monitoring Mar 25, 2026, 05:59 PM UTC

   Identified the issue and rolled a fix for resolution. we are actively monitoring.

4. resolved Mar 25, 2026, 06:11 PM UTC

   The issue has been successfully resolved, and the service is now fully operationa

Read the full incident report →

Started Mar 23, 2026, 03:27 PM UTC· resolved Mar 23, 2026, 11:26 PM UTC

1. investigating Mar 23, 2026, 03:27 PM UTC

   We are investigating the incident.

2. identified Mar 23, 2026, 04:23 PM UTC

   We identified the issue and are working deploying the mitigation.

3. identified Mar 23, 2026, 05:51 PM UTC

   We’ve identified the issue and are continuing to deploy mitigation. Work is ongoing, and we’re closely monitoring progress toward full resolution.

4. identified Mar 23, 2026, 07:26 PM UTC

   We are actively working on a fix and taking steps to minimize the impact. We will continue to share updates as they become available.

5. monitoring Mar 23, 2026, 10:13 PM UTC

   The issue has been resolved, and we are currently monitoring the system to ensure stabilit

6. monitoring Mar 23, 2026, 10:17 PM UTC

   The issue has been resolved, and we are currently monitoring the system to ensure stabilit

7. resolved Mar 23, 2026, 11:26 PM UTC

   The issue has been resolved.

8. postmortem Mar 26, 2026, 08:06 PM UTC

   ## _Customer Impact_ Between March 18, 2026 at 7:54 pm UTC and March 23, 2026 at 10:10 pm UTC, a subset of customers were unable to create or edit VPN Gateways within the UiPath Automation Cloud Administration portal. Attempts to perform these actions returned errors, preventing any configuration changes to VPN Gateways. Existing VPN Gateways continued to function normally throughout, while create and edit operations were affected. This issue impacted customers across all commercial cloud regions. Our regulated \(GXP\) environment was confirmed unaffected at any point during the incident. ## _Root Cause_ A recent update to the VPN Gateway management service introduced a change in the data structures used for creation and editing operations. There was a deployment misalignment between front-end services and back-end services, and as a result, any attempt to create or edit a VPN Gateway failed with an error, while existing VPN Gateways continued to operate normally. Recovery required deploying updated back-end services to all regions. ## _Detection_ The incident was detected on March 23, 2026 at 3:05 pm UTC, and within minutes of onset, our engineering team assembled via a dedicated incident bridge to begin an investigation. The incident was formally declared as a critical, customer-impacting event at 3:21 pm UTC, and a public impact statement was posted to our status page by 3:28 pm UTC. ## _Response_ Upon detection, our engineering team convened immediately to investigate the root cause. Initial analysis confirmed that VPN Gateway creation and editing were consistently failing across all commercial cloud regions, while existing connections remained operational. The team reviewed recent changes to the VPN Gateway management service and identified the front-end changes as the likely cause. A proposed fix was prepared by 3:09 pm UTC, and a corrective build was initiated by 4:04 pm UTC. The fix rollout began at 5:28 pm UTC. However, by 7:15 pm UTC, the team determined that this initial fix did not resolve the issue as expected. The team immediately pivoted to an alternative approach, estimating approximately one hour to build and validate the new solution. A status page update was posted at 7:19 pm UTC to inform customers that the root cause had been identified and a fix remained in progress. The alternative fix was validated in the India region at approximately 8:41 pm UTC and confirmed to be effective. Rollout to all remaining regions began at 9:02 pm UTC and proceeded in a controlled manner. By 10:10 pm UTC, the corrected version was deployed globally, and all affected VPN Gateway creation and editing functionality was fully restored. The incident was formally marked as mitigated at 10:20 pm UTC. Status page updates were posted at key milestones throughout the incident to keep customers informed, and we are taking steps to improve our communication cadence during extended incidents \(see Follow-Up below\). ## _Follow-Up_ To prevent similar incidents in the future, we are implementing several targeted improvements to address the underlying issue of unsynchronized changes between frontend and backend components: 1. We are enforcing feature flags into our release process for the VPN Gateway management service, allowing frontend and backend validation changes to be deployed in a coordinated manner and enabled only when both components are fully aligned, while also ensuring these changes are thoroughly tested against a comprehensive set of configuration scenarios before reaching production. 2. We are introducing new integration tests that ensure frontend and backend changes are validated together before release. 3. We are enhancing our monitoring to include dedicated alerts for failed configuration operations, enabling faster detection of issues that may arise from mismatches between client-side and server-side validation.

Read the full incident report →

Started Mar 23, 2026, 11:42 AM UTC· resolved Mar 23, 2026, 12:34 PM UTC

1. investigating Mar 23, 2026, 11:42 AM UTC

   New connection creation in UiPath Integration Service is currently failing in the Europe region. Existing connections and running automations are not impacted. The team is actively working to resolve the issue. We will continue to provide updates on status.

2. monitoring Mar 23, 2026, 12:00 PM UTC

   A fix has been deployed and the service is recovered. Current status: We are monitoring the system to ensure stability and full recovery.

3. resolved Mar 23, 2026, 12:34 PM UTC

   The issue has been resolved.

4. postmortem Apr 01, 2026, 03:40 PM UTC

   ## Customer impact We understand how important reliable access to your integrations is, and we sincerely apologize for the disruption this incident caused to your work. Between March 23, 2026 at 10:30 am UTC and March 23, 2026 at 11:45 am UTC \(approximately 75 minutes\), a subset of customers in the EU region were unable to create or authenticate connections through the UiPath Integration Service™. During this window, the vast majority of new connection requests failed, returning errors when you attempted to set up or authenticate a connection. Retrieving existing connections, running workflows, and all previously established connections continued to function normally throughout the incident. Only operations that required establishing a new connection were affected, including requests originating from UiPath Studio™ and Studio Web. Failures began gradually around 10:15 am UTC, escalated to a near-complete disruption by 10:30 am UTC, and persisted until approximately 11:45 am UTC when the service was restored to normal operation. ## Root cause A scheduled maintenance activity was performed on the data layer supporting the Integration Service in the US region at approximately 10:20 am UTC on March 23, 2026. During this maintenance, the data service used by the EU region’s Integration Service was temporarily disrupted. A configuration mismatch caused the EU region’s Integration Service deployment to reference a data service hosted in the US region rather than the correct regional service. When the maintenance activity disrupted that US-hosted service, all attempts to establish new connections in the EU region began failing—causing the service to return errors to users. Because the connection creation and authentication flows depend on this data service, these operations also failed. The scope of impact was limited to establishing new connections; all other Integration Service operations—including retrieving existing connections and running active workflows—remained fully functional, as they did not rely on the affected service. ## Detection Our monitoring systems detected elevated error rates on the Integration Service in the EU region at approximately 10:30 am UTC on March 23, 2026—within minutes of the disruption beginning. Our engineering team was alerted and began investigating immediately. Further analysis revealed a consistent error pattern across all failing connection requests, correlating directly with the timing of the scheduled maintenance activity in the US region. This correlation allowed our team to quickly narrow the investigation to the cross-region configuration mismatch. ## Response Our team correlated the onset of failures at 10:30 am UTC with the scheduled maintenance in the US region. Investigation confirmed that the EU region’s Integration Service was incorrectly configured to reference a US-hosted data service. Our investigation verified that every failing connection request encountered the same underlying error, confirming the cross-region configuration mismatch as the root cause. The configuration for the EU region was corrected to reference the appropriate regional service. Service recovery was observed at approximately 11:45 am UTC, with new connection creation returning to normal operation. We confirmed that only new connection creation—and the dependent authentication flows—was affected throughout the incident. ## Follow-up We are introducing automated pre-deployment checks to validate that each regional deployment references the correct region-specific data service. These checks will run before every deployment, preventing cross-region configuration mismatches from reaching production. In parallel, we are updating our maintenance procedures to include a mandatory step that identifies and validates all services with dependencies on the target data service before initiating any maintenance activity. To improve our detection speed, we are adding dedicated alerts for new connection failure rates per region, with thresholds that trigger immediate notification when the error rate exceeds 5% over a five-minute window. These alerts will ensure that any similar disruption is surfaced to our engineering team within minutes. Finally, we are conducting a comprehensive audit of all production region configurations across Integration Service deployments to identify and remediate any remaining cross-region inconsistencies. We are committed to ensuring that your experience with the Integration Service remains reliable and that the safeguards we are putting in place prevent a recurrence of this type of incident.

Read the full incident report →

Started Mar 20, 2026, 07:28 AM UTC· resolved Mar 20, 2026, 07:57 AM UTC

1. investigating Mar 20, 2026, 07:28 AM UTC

   We are currently investigating reports of an issue in Integration Service in Singapore region. Impact: Integration Service existing connections are not visible in Orchestrator, and attempts to create a new connection result in no response Our teams are actively working to identify the cause and assess the scope of the issue. Further updates will be shared as soon as more information becomes available.

2. investigating Mar 20, 2026, 07:29 AM UTC

   We are currently investigating reports of an issue in Integration Service in multiple regions. Impact: Integration Service existing connections are not visible in Orchestrator, and attempts to create a new connection result in no response Our teams are actively working to identify the cause and assess the scope of the issue. Further updates will be shared as soon as more information becomes available.

3. monitoring Mar 20, 2026, 07:42 AM UTC

   A fix has been deployed and the service is recovering. Current status: We are monitoring the system to ensure stability and full recovery. Further updates will be shared soon

4. resolved Mar 20, 2026, 07:57 AM UTC

   The issue has been resolved. The system has remained stable during the monitoring period.

Read the full incident report →

Started Mar 18, 2026, 07:52 PM UTC· resolved Mar 18, 2026, 10:34 PM UTC

1. identified Mar 18, 2026, 07:52 PM UTC

   We have identified the cause of the disruption impacting Prepare Python environment step for Agents in Multiple Regions and are actively implementing a fix. Impact: Coded agents failed at the Prepare Python environment step when requires-python>=3.12 was set in pyproject.toml. Workaround: Remove or lower the requires-python constraint in pyproject.toml to >=3.11 until the fix is deployed. Next update: Additional updates will be provided as remediation continues.

2. identified Mar 18, 2026, 08:46 PM UTC

   We are actively working on implementing a fix. Impact: Coded agents failed at the Prepare Python environment step when requires-python>=3.12 was set in pyproject.toml. Workaround: Remove or lower the requires-python constraint in pyproject.toml to >=3.11 until the fix is deployed. Next update: Additional updates will be provided as remediation continues.

3. resolved Mar 18, 2026, 10:34 PM UTC

   We are actively working on implementing a fix. Impact: Coded agents failed at the Prepare Python environment step when requires-python>=3.12 was set in pyproject.toml. Workaround: Remove or lower the requires-python constraint in pyproject.toml to >=3.11 until the fix is deployed. Next update: Additional updates will be provided as remediation continues.

4. postmortem Apr 17, 2026, 04:53 PM UTC

   ## **Customer Impact** Between March 16, 2026 12:30 PM and March 18, 2026 at 9:55 pm UTC, a subset of customers experienced failures when running coded agents. Agent execution failed during the "Prepare Python environment" step when the agent's configuration specified a minimum Python version of 3.12 or higher. Customers using UiPath Agents or coded agents configured for Python 3.11 were unaffected. The impact was limited to coded agents in all production regions except Europe, where the affected version had not yet been deployed. A workaround was available — lowering the Python version requirement to 3.11 in the agent's configuration — though this required repackaging and republishing the agent. ## **Root Cause** As part of a security improvement, the Python installation method in the agent runtime environment was updated. The new configuration restricted the package manager's ability to download and install Python versions on demand at runtime. The runtime environment was deployed with only Python 3.11 pre-installed, while Python 3.12 and 3.13 — which are also supported versions — were not included. As a result, coded agents specifying a minimum Python version of 3.12 or higher could not prepare their execution environment and failed to start. The issue originated from a version mismatch within a layered deployment architecture composed of multiple dependent components. During staging validation, the regression was identified and corrected in one component layer. However, during the subsequent promotion cycle, an older version of that layer was inadvertently referenced in the final deployment configuration. As a result, the production environment was deployed without the full set of supported Python versions. ## **Detection** The issue was identified on March 18, 2026 at 7:30 pm UTC after internal stakeholders observed job failures. Following incident initiation by our engineering team, the impact was quickly confirmed to be isolated to Coded Agents, specifically agents requiring Python 3.12 or higher. ## **Response** Our engineering team evaluated reverting the change but determined that doing so would negatively impact other agent types. The team chose a forward fix: rebuilding the runtime environment to include all supported Python versions \(3.11, 3.12, and 3.13\) and redeploying across affected regions. The updated environment was deployed to all affected regions by 9:55 pm UTC on March 18, 2026, and service was fully restored. The incident was formally closed at 10:37 pm UTC. ## **Follow-up** To prevent similar incidents, we are implementing the following improvements: * **Pre-deployment validation:** Automated checks in the deployment pipeline to verify that all supported Python versions are included in the runtime environment before deployment. * **Automated alerting:** Expanded monitoring to detect and alert on failures in the agent environment preparation step. * **Enhanced change review:** Configuration changes affecting agent runtime environments will require compatibility testing across all supported agent types before deployment.

Read the full incident report →

Started Mar 17, 2026, 08:01 AM UTC· resolved Mar 17, 2026, 10:50 AM UTC

1. investigating Mar 17, 2026, 08:01 AM UTC

   We are currently investigating degraded performance affecting IXP in the US region. Affected functionality: - Automations utilizing IXP may experience increased latency - Some requests may return HTTP 503 errors Next steps: Our team is actively investigating the root cause and working to restore full service. No action is required from customers at this time.

2. investigating Mar 17, 2026, 09:47 AM UTC

   Our team is making progress in identifying the root cause and is actively working diligently to mitigate the issue. No action is required from customers at this time.

3. monitoring Mar 17, 2026, 10:33 AM UTC

   A fix has been deployed to address the issue. We are actively monitoring the environment to confirm full service restoration.

4. resolved Mar 17, 2026, 10:50 AM UTC

   The fix has been deployed and service has been restored

Read the full incident report →