UiPath incident
Failures in App and Coded Apps requests in all regions
Resolved after 16 minutes, on October 14, 2026.
## Customer impact Between 06:38 UTC and 07:21 UTC on October 14, 2026, a portion of requests to UiPath Apps, Coded Apps, and solutions that depend on them failed in eleven regions: Europe, United States, Community, Japan, Singapore, Australia, Canada, South Korea, Switzerland, UAE, and the delayed US environment. The India and United Kingdom regions were not affected. About 2 percent of requests failed overall, between 0.6 and 5 percent depending on the region. Affected users saw applications fail to load, requests return server errors, or slow responses. In regions where service pods had to be restarted, Apps was unreachable for up to about eight minutes. Response times were back to normal in every region by 07:40 UTC. Most users of already running published apps noticed little or nothing. App definitions are cached in the browser for up to 24 hours, app data comes from Data Service and Orchestrator rather than this database, and the service kept using the database connections it already held. The requests that failed were those needing a new database connection: opening the designer or the apps list, loading an app not yet cached, downloading documents and images stored in Apps, and saving or publishing. ## Root cause At 06:38 UTC, while database access was being set up for a new regional deployment, the password of the database user that the Apps service uses was changed. That user is shared by the production database clusters of all affected regions, so the change applied to all of them at once. The running services still held the previous password and could no longer open new database connections. The India and United Kingdom regions do not use this credential and were not affected. The change was meant to create a separate database user for the new region. Instead, the password of the existing user that all regions share was changed. Our change process for database credentials did not clearly separate creating a new credential from modifying an existing one, and it did not require a check of how many clusters and regions a credential change would affect. Combined with a single database user being shared across regions, this allowed a change intended for one region to cause a multi-region outage. ## Detection Our internal monitoring raised the first alert at 06:41 UTC, three minutes after the first failures, and alerts for every affected region followed by 06:46 UTC. At 06:50 UTC the on-call engineer confirmed that every production cluster was being refused by its database and started the incident process. ## Response At 07:05 UTC the previous password was restored and authentication failures stopped everywhere. Most regions reconnected automatically. In the regions that did not, the service pods were restarted or redeployed: Delayed US at 07:21 UTC and Switzerland by 07:30 UTC. Request failures stopped at 07:21 UTC, response times were back to baseline by 07:40 UTC, and we continued monitoring until the incident was resolved at 07:43 UTC. ## Follow up To prevent this from happening again, we are: - Introducing a defined procedure for creating and rotating database credentials, with a pre-change review that states which clusters and regions share the credential, and a staged rollout that is verified in one region before it is applied more widely. - Moving to separate, least-privilege database users for each region, so that a change in one region cannot affect another. - Automatically declaring an incident and paging the database owners when the same database error is detected in several regions at once, instead of relying on manual escalation from individual regional alerts. - Enabling services to pick up updated database credentials without a restart, and to reconnect faster after an authentication failure.
Update timeline
- monitoring Oct 14, 2026, 07:26 AM UTC
Starting with 6:50 UTC we have experienced a global outage that has affected the loading of apps and coded apps all regions except for India and UK. Outage has been resolved and the services are fully operational. Impact: No ongoing user impact.
- resolved Oct 14, 2026, 07:43 AM UTC
Starting with 6:50 UTC we have experienced a global outage that has affected the loading of apps and coded apps all regions except for India and UK. Outage has been resolved and the services are fully operational. Impact: No ongoing user impact.
- postmortem Oct 23, 2026, 12:08 PM UTC
## Customer impact Between 06:38 UTC and 07:21 UTC on October 14, 2026, a portion of requests to UiPath Apps, Coded Apps, and solutions that depend on them failed in eleven regions: Europe, United States, Community, Japan, Singapore, Australia, Canada, South Korea, Switzerland, UAE, and the delayed US environment. The India and United Kingdom regions were not affected. About 2 percent of requests failed overall, between 0.6 and 5 percent depending on the region. Affected users saw applications fail to load, requests return server errors, or slow responses. In regions where service pods had to be restarted, Apps was unreachable for up to about eight minutes. Response times were back to normal in every region by 07:40 UTC. Most users of already running published apps noticed little or nothing. App definitions are cached in the browser for up to 24 hours, app data comes from Data Service and Orchestrator rather than this database, and the service kept using the database connections it already held. The requests that failed were those needing a new database connection: opening the designer or the apps list, loading an app not yet cached, downloading documents and images stored in Apps, and saving or publishing. ## Root cause At 06:38 UTC, while database access was being set up for a new regional deployment, the password of the database user that the Apps service uses was changed. That user is shared by the production database clusters of all affected regions, so the change applied to all of them at once. The running services still held the previous password and could no longer open new database connections. The India and United Kingdom regions do not use this credential and were not affected. The change was meant to create a separate database user for the new region. Instead, the password of the existing user that all regions share was changed. Our change process for database credentials did not clearly separate creating a new credential from modifying an existing one, and it did not require a check of how many clusters and regions a credential change would affect. Combined with a single database user being shared across regions, this allowed a change intended for one region to cause a multi-region outage. ## Detection Our internal monitoring raised the first alert at 06:41 UTC, three minutes after the first failures, and alerts for every affected region followed by 06:46 UTC. At 06:50 UTC the on-call engineer confirmed that every production cluster was being refused by its database and started the incident process. ## Response At 07:05 UTC the previous password was restored and authentication failures stopped everywhere. Most regions reconnected automatically. In the regions that did not, the service pods were restarted or redeployed: Delayed US at 07:21 UTC and Switzerland by 07:30 UTC. Request failures stopped at 07:21 UTC, response times were back to baseline by 07:40 UTC, and we continued monitoring until the incident was resolved at 07:43 UTC. ## Follow up To prevent this from happening again, we are: - Introducing a defined procedure for creating and rotating database credentials, with a pre-change review that states which clusters and regions share the credential, and a staged rollout that is verified in one region before it is applied more widely. - Moving to separate, least-privilege database users for each region, so that a change in one region cannot affect another. - Automatically declaring an incident and paging the database owners when the same database error is detected in several regions at once, instead of relying on manual escalation from individual regional alerts. - Enabling services to pick up updated database credentials without a restart, and to reconnect faster after an authentication failure.
Your product runs on more than UiPath
Add the vendors you depend on and get one message when any of them reports trouble. Free for 3 vendors, no card.
Amazon Web Services