UiPath incident

[Canada] [Automation Hub] Sporadic login failures

Resolved after 5 hours 16 minutes, on October 26, 2026.

postmortem Nov 09, 2026, 06:52 PM UTC

**Customer impact** On 26 October 2026, from 19:08 UTC, some users in the Automation Hub Canada region could not sign in, and some Automation Hub Open API calls failed with a "Database Connection Error". Service was fully restored at 00:24 UTC on 27 October. Other regions were not affected. Your Automation Hub data was not affected. Failed requests were rejected before they reached any tenant's data, and no data was lost or changed. **Root cause** UiPath was responding to a security event in its internal corporate environment. As part of that response, access for internal service accounts was reviewed and removed as a precaution. At 15:39 UTC, the service account that Automation Hub uses to read its tenant database credentials lost access to the store that holds them. Automation Hub keeps a cached copy of each tenant's credential for up to 14 days, so service continued normally at first. From 19:08 UTC, tenants in Canada whose cached copy had expired could no longer connect to their database. This is the "Database Connection Error" that some customers saw. Tenants whose cached copy was still valid were not affected. Our investigation found no evidence that the unauthorized party accessed Automation Hub or customer data. The outage was caused by our precautionary actions, not by the security event itself. **Detection** Our engineers saw the failures on our availability monitoring at 19:23 UTC, 15 minutes after they began in Canada, and identified the cause at 19:34 UTC. **Response** - 19:47 UTC: we escalated to the team running the security response. - 20:21 UTC: as a precaution, it was decided to replace Automation Hub's credential before restoring its access. - 23:11 UTC: the new credential was created. - 00:24 UTC on 27 October: access was restored, and Canada recovered with no restart needed. **Follow up** - Build tooling to identify all the production services that use a service account, before its access is changed. - Alert our engineers as soon as Automation Hub loses access to its credential store, rather than when failures start after cached credentials expire. - Prepare and pre-approve the steps to replace Automation Hub's production credentials, so access can be restored faster during a security response.

Started
Oct 26, 2026, 07:08 PM UTC
Resolved
Oct 27, 2026, 12:24 AM UTC
Duration
5h 16m
Detected by Pingoru
Oct 26, 2026, 07:08 PM UTC

Update timeline

  1. resolved Oct 26, 2026, 06:00 PM UTC

    Due to an expired credential configuration, some customers were unable to access Automation Hub in the Canada region on 2026-10-26. The credential was rotated shortly after the failures were detected, and all logins were succeeding again after 2026-10-27:01:00:00z.

  2. postmortem Nov 09, 2026, 06:52 PM UTC

    **Customer impact** On 26 October 2026, from 19:08 UTC, some users in the Automation Hub Canada region could not sign in, and some Automation Hub Open API calls failed with a "Database Connection Error". Service was fully restored at 00:24 UTC on 27 October. Other regions were not affected. Your Automation Hub data was not affected. Failed requests were rejected before they reached any tenant's data, and no data was lost or changed. **Root cause** UiPath was responding to a security event in its internal corporate environment. As part of that response, access for internal service accounts was reviewed and removed as a precaution. At 15:39 UTC, the service account that Automation Hub uses to read its tenant database credentials lost access to the store that holds them. Automation Hub keeps a cached copy of each tenant's credential for up to 14 days, so service continued normally at first. From 19:08 UTC, tenants in Canada whose cached copy had expired could no longer connect to their database. This is the "Database Connection Error" that some customers saw. Tenants whose cached copy was still valid were not affected. Our investigation found no evidence that the unauthorized party accessed Automation Hub or customer data. The outage was caused by our precautionary actions, not by the security event itself. **Detection** Our engineers saw the failures on our availability monitoring at 19:23 UTC, 15 minutes after they began in Canada, and identified the cause at 19:34 UTC. **Response** - 19:47 UTC: we escalated to the team running the security response. - 20:21 UTC: as a precaution, it was decided to replace Automation Hub's credential before restoring its access. - 23:11 UTC: the new credential was created. - 00:24 UTC on 27 October: access was restored, and Canada recovered with no restart needed. **Follow up** - Build tooling to identify all the production services that use a service account, before its access is changed. - Alert our engineers as soon as Automation Hub loses access to its credential store, rather than when failures start after cached credentials expire. - Prepare and pre-approve the steps to replace Automation Hub's production credentials, so access can be restored faster during a security response.

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.

Add your stack →