- Overview
- Get started
- Concepts
- Using UiPath CLI
- How-to guides
- CI/CD recipes
- Command reference
- Overview
- Exit codes
- Global options
- uip codedagent
- uip coder
- uip context-grounding
- uip docsai
- uip function
- uip guardrails
- uip llm-configuration
- uip llm-gateway
- uip maestro authoring
- uip maestro registry
- uip model-hub
- activities find
- activities get-default-xaml
- analyze
- analyzer-rules list
- build
- cleanup
- data-fabric-entities install
- data-fabric-entities list
- files diff
- get-library-object-repository
- get-object-repository
- init
- instances list
- pack
- packages inspect
- packages install
- packages versions
- publish
- remote
- restore
- run, debug & execution
- settings
- studio start
- templates search
- test-data add-entity
- test-data add-queue
- test-data add-variation
- tm
- uia
- validate
- workflow-examples get
- workflow-examples list
- uip tasks
- uip traces
- uip traces feedback
- Migration
- Reference & support
uip tm wait
Syntax and options for `uip tm wait`, which polls a test execution until it reaches a terminal state and prints a one-line summary.
uip tm wait polls a test execution until it reaches a terminal state (Finished or Cancelled) and then prints a one-line summary. It turns the asynchronous uip tm testsets run into a blocking step in a CI pipeline.
wait is registered as a top-level verb under tm, not as a resource. Invoke it as uip tm wait, not uip tm executions wait.
Synopsis
uip tm wait --execution-id <uuid> (--project-key <key> | --project-id <id> | --test-set-key <key>)
[--timeout <seconds>]
uip tm wait --execution-id <uuid> (--project-key <key> | --project-id <id> | --test-set-key <key>)
[--timeout <seconds>]
Honors the global options. See the Exit codes section below for the domain-specific behavior on timeout.
uip tm wait
Block until the given execution reaches a terminal state, polling Test Manager every 60 seconds.
Arguments
None.
Options
-
--execution-id <uuid>(required) — execution to wait on. Get it fromuip tm testsets run. -
--project-key <key>— owning project key. -
--project-id <id>— owning project ID. Use instead of--project-key.Pass
--project-id,--project-key, or--test-set-key. When you pass more than one,--project-idis used first, then--project-key, then the project prefix of--test-set-key. -
--test-set-key <key>— test set key (for example,DEMO:42); the project key is derived from the prefix. -
--timeout <seconds>— maximum time to wait, in seconds. Defaults to1800(30 minutes). Pass0to wait indefinitely.
There is no --poll-interval flag on this command. The poll interval is fixed at 60 seconds.
A manual run closed early with executions finish keeps Status: "Running", so wait never sees a terminal state on it. wait blocks until --timeout and then exits 2. Check such a run's ExecutionFinished timestamp with executions get-stats instead.
Example
# wait up to 15 minutes
uip tm wait \
--execution-id a1b2c3d4-0000-0000-0000-000000000001 \
--project-key DEMO \
--timeout 900
# wait up to 15 minutes
uip tm wait \
--execution-id a1b2c3d4-0000-0000-0000-000000000001 \
--project-key DEMO \
--timeout 900
Data shape (terminal state reached before the timeout)
{
"Code": "WaitComplete",
"Data": {
"ExecutionId": "a1b2c3d4-0000-0000-0000-000000000001",
"Status": "Finished",
"EndTime": "2025-04-15T10:32:11Z",
"Duration": "00:02:11"
}
}
{
"Code": "WaitComplete",
"Data": {
"ExecutionId": "a1b2c3d4-0000-0000-0000-000000000001",
"Status": "Finished",
"EndTime": "2025-04-15T10:32:11Z",
"Duration": "00:02:11"
}
}
Status is the terminal state Test Manager reports: Finished or Cancelled. Reaching a terminal state is the success signal for wait; the verb exits 0 whether the tests inside the execution passed or failed. To branch on pass or fail, read the report get output after wait returns.
Exit codes
wait follows the standard exit codes for 0, 1, and 3, with one domain-specific reuse of 2:
| Exit code | Meaning |
|---|---|
0 | Execution reached a terminal state within the timeout. |
1 | Polling failed (three consecutive API errors, interrupt, abort), sign-in failed, or no project was given. See the Message field for detail. |
2 | Timed out. The timeout elapsed before the execution reached a terminal state. |
3 | Validation error (bad flag value, missing required option). |
Exit code 2 is domain-specific. The shared CLI contract reserves 2 for AuthenticationError, but wait reuses it for timeout so that scripts can distinguish "took too long" from "polling failed" without parsing text. uip tm run uses 4 for its own timeout instead. See Exit-code behavior on executions for the full pattern.
Script pattern
uip tm wait \
--execution-id "$id" \
--project-key DEMO \
--timeout 1800
case $? in
0) ;;
2) echo "timed out" >&2; exit 2 ;;
*) echo "wait failed" >&2; exit 1 ;;
esac
uip tm wait \
--execution-id "$id" \
--project-key DEMO \
--timeout 1800
case $? in
0) ;;
2) echo "timed out" >&2; exit 2 ;;
*) echo "wait failed" >&2; exit 1 ;;
esac
Related
- testsets run — produces the
ExecutionIdto wait on. - report — summary to read once
waitreturns0. - result — JUnit XML export.
- executions retry — re-run the failed cases of a finished execution.
- executions cancel — stop a running automated execution; poll it to
Cancelledwithwait. - run — run every test in an uploaded package, wait, and write a report in one command.
See also
- Test Manager overview
- Exit codes — shared contract.
- Scripting patterns — the launch-wait-verify pipeline.