Customer impact

Between September 14, 2026 at 12:45 UTC and September 16, 2026 at 17:30 UTC, a subset of customers experienced failures when Maestro processes attempted to create human-in-the-loop tasks in Action Center. The first customer report reached UiPath on September 16 at 12:24 UTC and an incident was declared at 14:37 UTC, so a number of process runs failed before the issue was formally identified.

Affected process runs faulted at the human-in-the-loop step with the error "Invalid input for the HITL task" and no Action Center task was created. No tasks were lost or duplicated, and no data was corrupted. Process runs that had already passed the human-in-the-loop step were not affected.

The impact was limited to a small subset of organizations, primarily in the United States, Canada, Australia, and India regions, whose Maestro processes met a specific condition: the process used an Action App and the app's folder path had no value at run time. Canada and Singapore received the change but had no affected process runs.

Action for affected customers: process runs that failed during this window did not recover automatically. If you have process runs that faulted at a human-in-the-loop step between September 14 and September 16 and have not yet been retried, please retry them from Maestro or contact UiPath Support with the process instance IDs.

Root cause

A recent Maestro service update added input validation to the human-in-the-loop task creation step. The change was intended to return a clear, non-retried error when a task is genuinely misconfigured, specifically when the Action App name is missing. The same validation also treated an empty app folder path as a misconfiguration.

An empty folder path is, however, a valid and supported configuration: Maestro resolves it to the folder of the running process. The new validation rejected the request before that default behavior could apply, so task creation failed for every process run in which the folder path was empty.

The change passed pre-production testing because the test processes all carried an explicit app folder path, so the empty-folder-path scenario was not exercised before release.

Detection

The issue was identified on September 16, 2026 at 12:24 UTC through customer-reported process failures. The new validation classified the failure as a user configuration error rather than a service error. Configuration errors in that category are intentionally excluded from our availability monitoring, so no automated alert fired and detection relied on customer reports. Our team opened an investigation immediately and confirmed within minutes that the failures originated in Maestro before any call to Action Center.

Response

At 3:24 pm UTC on September 16, 2026, we posted a public status update acknowledging Action Center task creation failures in Maestro. By 3:28 pm UTC the cause had been identified as the recent validation change, and by 4:30 pm UTC we communicated that a fix was being applied to the affected regions.

The fix removed the validation that blocked task creation when the folder path was empty, restoring the previous default behavior. After verifying the fix in our testing environment against the exact empty-folder-path scenario, deployment to production began at 4:33 pm UTC and completed across all affected regions by 5:29 pm UTC. The incident was marked as mitigated at 5:44 pm UTC.

We continued monitoring recovery and customer-reported behavior. A follow-up status update was posted at 6:56 pm UTC, and the incident was resolved at 7:41 pm UTC after confirming with affected customers that new and retried processes were completing successfully.

The incident was declared resolved at 19:41 UTC after confirming with affected customers that new and retried processes were completing successfully. From first failed run to last, the defect was live in production for 52 hours and 45 minutes; the declared incident covered the final 5 hours and 3 minutes.

Follow up

1. Re-apply the intended improvement in a corrected form: return a clear error only when the Action App name is missing, and leave the empty-folder-path default behavior unchanged. The corrected change is under review and will be released with standard validation.
2. Add an automated end-to-end test that runs with exact customer scenario to catch these sort of issues early.
3. Add alerting for spikes in this class of task-creation errors that operates independently of availability monitoring
4. Add alerts for 4xx anomalies to catch other unexpected issues.
5. Provide tooling to identify and retry failed process runs in bulk after a fix is deployed, so recovery does not depend on manual retries by customers.