Resolved: 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.

Identified: 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.

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

Investigating: We are investigating customer reports of errors with Action Center

Postmortem: # 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

Resolved: The issue is fixed and service is healthy.

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

Investigating: 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.

Resolved: Issue is now resolved.

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

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

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

Resolved: 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.

Identified: 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.

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

Investigating: We are investigating customer reports of errors with Action Center

Resolved: This incident is mitigated.

Monitoring: 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.

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

Postmortem: # 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

Resolved: The issue is fixed and service is healthy.

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

Investigating: 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.

Postmortem: # 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.

Resolved: Issue is now resolved.

Identified: 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.

Identified: 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.

Investigating: 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.

Resolved: Issue is now resolved.

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

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

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

Resolved: 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.

Identified: 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.

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

Investigating: We are investigating customer reports of errors with Action Center

Postmortem: # 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

Resolved: The issue is fixed and service is healthy.

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

Investigating: 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.

Postmortem: # 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.

Resolved: Issue is now resolved.

Identified: 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.

Identified: 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.

Investigating: 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.

Resolved: 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.

Identified: 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.

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

Investigating: We are investigating customer reports of errors with Action Center

Postmortem: # 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

Resolved: The issue is fixed and service is healthy.

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

Investigating: 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.

Resolved: 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.

Identified: 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.

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

Investigating: We are investigating customer reports of errors with Action Center

Postmortem: # 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

Resolved: The issue is fixed and service is healthy.

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

Investigating: 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.

Resolved: Issue is now resolved.

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

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

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