uip tm executions

Syntax and options for `uip tm executions`, which lists, filters, exports, re-runs, retries, finishes, cancels, and deletes test executions, sets their reporting date, and lists their test case logs.

uip tm executions inspects and manages test executions, the objects produced by uip tm testsets run. These verbs list, filter, and export executions; read an execution's stats and test case logs; re-run an execution or retry only its failed cases; close a manual run early or cancel an automated one; book a run against a reporting date; and delete a run.

The command that starts an execution is uip tm testsets run, which returns an ExecutionId. Every verb on this page except list, list-filtered, and export takes that ID.

Synopsis

uip tm executions list (--project-key <key> | --project-id <id>) [--test-set-id <uuid>] [--filter <text>] [--status <status>] [--execution-type <type>] [--execution-finished-interval <interval>] [--limit <n>] [--offset <n>]
uip tm executions list-filtered (--project-key <key> | --project-id <id>) [--test-set-id <uuid>] [--status <status>] [--execution-type <type>] [--execution-finished-interval <interval>] [--updated-by <userId>] [--search <text>] [--labels <labels...>] [--test-execution-ids <ids...>] [--sort-by <expr>] [--limit <n>] [--offset <n>]
uip tm executions export (--project-key <key> | --project-id <id>) --output-file <path> [--test-set-id <uuid>] [--status <status>] [--execution-type <type>] [--execution-finished-interval <interval>] [--updated-by <userId>] [--search <text>] [--labels <labels...>] [--test-execution-ids <ids...>] [--sort-by <expr>]
uip tm executions testcaselogs list --execution-id <uuid> (--project-key <key> | --project-id <id>) [--only-failed] [--filter <text>] [--results <results...>] [--statuses <statuses...>] [--duration-period <period>] [--limit <n>] [--offset <n>]
uip tm executions run (--project-key <key> | --project-id <id>) --execution-id <uuid> --execution-type <type> [--test-case-log-ids <ids...>] [--async]
uip tm executions retry --execution-id <uuid> (--project-key <key> | --project-id <id> | --test-set-key <key>) [--execution-type <type>]
uip tm executions get-stats --execution-id <uuid> (--project-key <key> | --project-id <id>)
uip tm executions finish --execution-id <uuid> (--project-key <key> | --project-id <id>)
uip tm executions cancel --execution-id <uuid> (--project-key <key> | --project-id <id>)
uip tm executions set-reporting-date --execution-id <uuid> --reporting-date <date> (--project-key <key> | --project-id <id>)
uip tm executions delete --execution-id <uuid> (--project-key <key> | --project-id <id>) --yes

All verbs honor the global options and the standard exit codes.

uip tm executions list

List the executions in a project, optionally limited to one test set.

Arguments

None.

Options

Flag	Description
--project-key <key>	Owning project key. Pass this or --project-id.
--project-id <id>	Owning project ID. Use instead of --project-key. When you pass both, --project-id is used.
--test-set-id <uuid>	Test set UUID (the Id field from testsets list, not TestSetKey). Omit to list executions across the project.
--filter <text>	Search executions by name.
--status <status>	Filter by a single execution status: pending, running, cancelling, finished, cancelled.
--execution-type <type>	Filter by a single execution type (automated, manual, mixed, none, autonomous).
--execution-finished-interval <interval>	Filter by how recently the execution finished: lastHour, lastDay, lastWeek, last15Days, last30Days.
--limit <n>	Page size. Defaults to 50.
--offset <n>	Results to skip. Defaults to 0.

Example

uip tm executions list \
  --project-key DEMO \
  --test-set-id a1b2c3d4-0000-0000-0000-000000000001 \
  --limit 2

Data shape

{
  "Code": "ExecutionsList",
  "Data": [
    {
      "Id": "b2c3d4e5-0000-0000-0000-000000000001",
      "Name": "Nightly Run 2025-04-15",
      "Status": "Finished",
      "Passed": 18,
      "Failed": 0
    },
    {
      "Id": "b2c3d4e5-0000-0000-0000-000000000002",
      "Name": "Nightly Run 2025-04-14",
      "Status": "Finished",
      "Passed": 16,
      "Failed": 2
    }
  ]
}

Each row carries the same fields as get-stats; the example shows a subset.

uip tm executions list-filtered

List the executions in a project using the full server-side filter set. No test set is required. --status and --execution-type each take a single value; filter by finish time with --execution-finished-interval.

Arguments

None.

Options

Flag	Description
--project-key <key>	Owning project key. Pass this or --project-id.
--project-id <id>	Owning project ID. Use instead of --project-key. When you pass both, --project-id is used.
--test-set-id <uuid>	Limit results to a single test set UUID (the Id from testsets list, not the test set key).
--status <status>	Filter by a single execution status: pending, running, cancelling, finished, cancelled.
--execution-type <type>	Filter by a single execution type (automated, manual, mixed, none, autonomous).
--execution-finished-interval <interval>	Filter by how recently the execution finished: lastHour, lastDay, lastWeek, last15Days, last30Days.
--updated-by <userId>	Filter by the user ID who last updated the execution.
--search <text>	Search executions by name.
--labels <labels...>	Space-separated label names to filter by.
--test-execution-ids <ids...>	Space-separated execution UUIDs to include.
--sort-by <expr>	Sort expression: a field name and a direction, for example 'executionFinished desc'.
--limit <n>	Page size. Defaults to 50.
--offset <n>	Results to skip. Defaults to 0.

Example

uip tm executions list-filtered \
  --project-key DEMO \
  --labels nightly regression \
  --status finished \
  --sort-by 'executionFinished desc' \
  --limit 10

Data shape

{
  "Code": "ExecutionsListFiltered",
  "Data": [
    {
      "Id": "b2c3d4e5-0000-0000-0000-000000000001",
      "Name": "Nightly Run 2025-04-15",
      "Status": "Finished",
      "ExecutionType": "automated",
      "Passed": 18,
      "Failed": 2
    }
  ]
}

Each row carries the same fields as get-stats; the example shows a subset.

uip tm executions export

Export the executions a filter matches to an .xlsx file, one row per execution with fixed columns. Each Name cell links back to Test Manager. The verb takes the same filters as list-filtered and reads every page itself, so it has no --limit or --offset. For one execution's own report file (Excel, PDF, or JUnit), use report export.

Needs the Test Manager execution-read permission and a licensed user, so a caller who can run list-filtered can still be refused here.

Note:

A filter that matches nothing still writes a valid workbook with no rows and returns Result: "Success". Check the filter, not the exit code.

Arguments

None.

Options

Flag	Description
--project-key <key>	Owning project key. Pass this or --project-id.
--project-id <id>	Owning project ID. Use instead of --project-key. When you pass both, --project-id is used.
--output-file <path>	Required. Path to write the .xlsx file to. Missing directories are created.
--test-set-id <uuid>	Limit results to a single test set UUID (the Id from testsets list, not the test set key).
--status <status>	Filter by a single execution status: pending, running, cancelling, finished, cancelled.
--execution-type <type>	Filter by a single execution type (automated, manual, mixed, none, autonomous).
--execution-finished-interval <interval>	Filter by how recently the execution finished: lastHour, lastDay, lastWeek, last15Days, last30Days.
--updated-by <userId>	Filter by the user ID who last updated the execution.
--search <text>	Search executions by name.
--labels <labels...>	Space-separated label names to filter by.
--test-execution-ids <ids...>	Space-separated execution UUIDs to include.
--sort-by <expr>	Sort expression: a field name and a direction, for example 'executionFinished desc'.

Example

uip tm executions export \
  --project-key DEMO \
  --test-set-id a1b2c3d4-0000-0000-0000-000000000010 \
  --output-file ./executions.xlsx

Data shape

{
  "Code": "ExecutionExport",
  "Data": {
    "OutputFile": "./executions.xlsx",
    "Bytes": 2048,
    "ProjectKey": "DEMO",
    "Result": "Exported"
  }
}

uip tm executions testcaselogs list

List the test case logs produced by one execution. Each log is one run of one test case, carrying its result, status, and timing.

Arguments

None.

Options

Flag	Description
--execution-id <uuid>	Required. Execution to inspect.
--project-key <key>	Owning project key. Pass this or --project-id.
--project-id <id>	Owning project ID. Use instead of --project-key. When you pass both, --project-id is used.
--only-failed	Show only failed logs.
--filter <text>	Search logs by name.
--results <results...>	Space-separated results to filter by: None, Passed, Failed, Restricted.
--statuses <statuses...>	Space-separated log statuses to filter by: pending, running, cancelling, cancelled, finished, failed.
--duration-period <period>	Filter by how long ago the log ran: last7Days, last15Days, last30Days, last90Days, last180Days, last365Days.
--limit <n>	Page size. Defaults to 50.
--offset <n>	Results to skip. Defaults to 0.

Example

uip tm executions testcaselogs list \
  --execution-id a1b2c3d4-0000-0000-0000-000000000001 \
  --project-key DEMO \
  --only-failed

Data shape

{
  "Code": "ExecutionTestCaseLogs",
  "Data": [
    {
      "Id": "c3d4e5f6-0000-0000-0000-000000000001",
      "TestCaseId": "a1b2c3d4-0000-0000-0000-000000000010",
      "TestExecutionId": "a1b2c3d4-0000-0000-0000-000000000001",
      "Result": "Failed",
      "Status": "Finished",
      "ExecutionType": "automated",
      "ExecutionStart": "2025-04-15T10:00:00Z",
      "ExecutionEnd": "2025-04-15T10:05:00Z",
      "Info": "Assertion failed on step 3",
      "TestCase": {
        "Id": "a1b2c3d4-0000-0000-0000-000000000010",
        "ObjKey": "DEMO:1",
        "Name": "Login flow"
      }
    }
  ]
}

Each row is the full test case log with its test case nested under TestCase; the example shows a subset. Each Id is a test case log UUID. Pass it to uip tm testcaselog list-assertions to see why a log was marked Failed.

uip tm executions run

Re-run an existing execution by its ID. This does not start a new execution; it replays within the same execution record, targeting all test cases or a specific subset of test case logs.

Note:

To start a new execution, use uip tm testsets run instead.

Arguments

None.

Options

Flag	Description
--project-key <key>	Owning project key. Pass this or --project-id.
--project-id <id>	Owning project ID. Use instead of --project-key. When you pass both, --project-id is used.
--execution-id <uuid>	Required. ID of the existing execution to re-run.
--execution-type <type>	Required. Which test cases to run (automated, manual, mixed, none, autonomous).
--test-case-log-ids <ids...>	Space-separated test case log UUIDs. When supplied, only those specific logs are re-run.
--async	Return immediately after queuing.

Examples

# re-run the entire execution
uip tm executions run \
  --project-key DEMO \
  --execution-id a1b2c3d4-0000-0000-0000-000000000001 \
  --execution-type automated

# re-run specific logs only
uip tm executions run \
  --project-key DEMO \
  --execution-id a1b2c3d4-0000-0000-0000-000000000001 \
  --execution-type automated \
  --test-case-log-ids c3d4e5f6-0000-0000-0000-000000000001 c3d4e5f6-0000-0000-0000-000000000002

Data shape

{
  "Code": "ExecutionRun",
  "Data": {
    "Id": "a1b2c3d4-0000-0000-0000-000000000001",
    "Status": "Succeeded"
  }
}

Status: "Succeeded" means Test Manager accepted the run request, not that the test cases passed. It reads the same with or without --async. Check the outcome with get-stats or wait.

uip tm executions retry

Retry only the failed test cases of a finished execution, in place. The command reads the execution's stats first and refuses a run whose status is not Finished or Cancelled. If no test case failed, it exits 0 with a message. The retry reuses the same execution ID.

Arguments

None.

Options

Flag	Description
--execution-id <uuid>	Required. Execution to retry.
--project-key <key>	Owning project key.
--project-id <id>	Owning project ID. Use instead of --project-key.
--test-set-key <key>	Test set key (for example, DEMO:42); the project key is derived from the prefix.
--execution-type <type>	Execution type for the retry: automated, manual, mixed, or none. Defaults to automated.

Pass --project-id, --project-key, or --test-set-key. When you pass more than one, --project-id is used first, then --project-key, then the project prefix of --test-set-key.

Example

uip tm executions retry \
  --execution-id a1b2c3d4-0000-0000-0000-000000000001 \
  --project-key DEMO

Data shape (failures to retry)

{
  "Code": "ExecutionRetry",
  "Data": {
    "ExecutionId": "a1b2c3d4-0000-0000-0000-000000000001",
    "Status": "Running",
    "StartTime": "2025-04-15T10:30:00Z",
    "RetriedCount": 3
  }
}

Data shape (no failures to retry)

{
  "Code": "ExecutionRetry",
  "Data": {
    "Message": "Execution 'a1b2c3d4-0000-0000-0000-000000000001' has no failed test cases to retry."
  }
}

uip tm executions get-stats

Get a test execution by ID with all its execution fields plus aggregated pass, fail, and none counts. Use it to check whether an execution has finished before calling report get, or to extract timing and coverage data for external reporting.

Arguments

None.

Options

Flag	Description
--execution-id <uuid>	Required. Test execution UUID. Get this from uip tm testsets run or uip tm testcases run.
--project-key <key>	Test Manager project key (for example, DEMO). Pass this or --project-id.
--project-id <id>	Test Manager project ID. Use instead of --project-key. When you pass both, --project-id is used.

Example

uip tm executions get-stats \
  --execution-id a1b2c3d4-0000-0000-0000-000000000001 \
  --project-key DEMO

Data shape

{
  "Code": "ExecutionStats",
  "Data": {
    "Id": "a1b2c3d4-0000-0000-0000-000000000001",
    "Name": "Nightly Run 2025-04-15",
    "Description": "Smoke + regression suite",
    "Status": "Finished",
    "ExecutionType": "automated",
    "Source": "TestManager",
    "SourceDetails": "",
    "ProjectId": "00000000-0000-0000-0000-000000000abc",
    "TestSetId": "a1b2c3d4-0000-0000-0000-000000000010",
    "TestSetObjKey": "DEMO:10",
    "TestSetScheduleId": "",
    "BatchExecutionKey": "",
    "Passed": 8,
    "Failed": 2,
    "None": 0,
    "Duration": 3600000,
    "RunId": 12,
    "EnforceExecutionOrder": false,
    "EnableCoverage": false,
    "IsRunningAutomated": false,
    "HasTestsFromMultipleAutomationProjects": false,
    "RemoteControlAccess": "Disabled",
    "ExecutionStart": "2025-04-15T10:00:00Z",
    "ExecutionFinished": "2025-04-15T11:00:00Z",
    "ReportingDate": "2025-04-15T11:00:00Z",
    "FolderKey": "11111111-2222-3333-4444-555555555555",
    "Created": "2025-04-15T09:55:00Z",
    "CreatedBy": "11111111-2222-3333-4444-555555555555",
    "Updated": "2025-04-15T11:00:00Z",
    "UpdatedBy": "11111111-2222-3333-4444-555555555555",
    "AutopilotForRobotsSettings": { "Enabled": false },
    "OrderedExecutionSettings": { "Enabled": false },
    "VideoRecordingSettings": { "Enabled": false }
  }
}

Field	Meaning
Passed, Failed, None	Aggregated test case log counts for the execution.
Duration	Total execution duration in milliseconds.
Status	Execution state. When Finished, the counts are final. A run closed early with finish keeps Status: "Running".
ExecutionFinished	When the run closed, by itself or through finish.
IsRunningAutomated	true while automated test cases are still being dispatched to robots.

Note:

get-stats returns the raw execution record with counts. For a formatted summary with per-test-case failure messages, use uip tm report get instead.

uip tm executions finish

Close a manual test execution early, while some of its test case logs are still unfinished. A run whose logs have all finished has already closed itself, so use this only to end one early. Test Manager refuses a run where no test case log has started yet, a run that already has an ExecutionFinished timestamp, and a run that came from Orchestrator. Needs the Test Manager manual-execution permission.

Warning:

finish stamps ExecutionFinished without setting Status, which stays Running. Recognize an early-closed run by its ExecutionFinished timestamp. uip tm wait on such a run blocks until its --timeout (default 1800 seconds) and then reports a timeout.

Arguments

None.

Options

Flag	Description
--execution-id <uuid>	Required. Execution to close.
--project-key <key>	Owning project key. Pass this or --project-id.
--project-id <id>	Owning project ID. Use instead of --project-key. When you pass both, --project-id is used.

Example

uip tm executions finish \
  --execution-id a1b2c3d4-0000-0000-0000-000000000002 \
  --project-key DEMO

Data shape

{
  "Code": "ExecutionFinish",
  "Data": {
    "Id": "a1b2c3d4-0000-0000-0000-000000000002",
    "Name": "UAT session 1",
    "Status": "Running",
    "ExecutionType": "Manual",
    "Passed": 1,
    "Failed": 0,
    "None": 1,
    "ExecutionStart": "2026-09-22T11:30:00Z",
    "ExecutionFinished": "2026-09-22T11:45:00Z"
  }
}

Data is the execution re-read after the close, with the same fields as get-stats; the example shows a subset. If the re-read fails, Data holds only Id.

uip tm executions cancel

Ask Test Manager to stop a running automated execution and its Orchestrator jobs. A manual run has no job to stop; close one with executions finish. Needs the automated-execution permission and a licensed user.

Result: "Success" means only that Test Manager accepted the request. Read Data.Status to learn what happened.

Data.Status	Meaning
Cancelling	Test Manager recorded the stop.
Running	The stop was forwarded to Orchestrator. The run reaches Cancelled when Orchestrator reports back.
A terminal status (Finished, Cancelled)	The run was already over.

Poll with uip tm wait until the run reaches a terminal status.

Arguments

None.

Options

Flag	Description
--execution-id <uuid>	Required. Execution to cancel.
--project-key <key>	Owning project key. Pass this or --project-id.
--project-id <id>	Owning project ID. Use instead of --project-key. When you pass both, --project-id is used.

Example

uip tm executions cancel \
  --execution-id a1b2c3d4-0000-0000-0000-000000000003 \
  --project-key DEMO

Data shape

{
  "Code": "ExecutionCancel",
  "Data": {
    "Id": "a1b2c3d4-0000-0000-0000-000000000003",
    "Name": "Regression Test Set - 20260922.1130",
    "Status": "Cancelling",
    "ExecutionType": "Automated",
    "Passed": 1,
    "Failed": 0,
    "None": 3,
    "ExecutionStart": "2026-09-22T11:30:00Z"
  }
}

Data is the execution re-read after the cancel request, with the same fields as get-stats; the example shows a subset. If the re-read fails, Data holds only Id.

uip tm executions set-reporting-date

Book a test execution against a given day, so reports count it on that day instead of the day it ran. Setting it again overwrites the previous date. Needs the execution-edit permission.

Note:

The date attaches to the run's result, which exists only once the run has closed. On an open run the command returns a 404 that names the result rather than the run. Close the run with testcaselog finish on every log, or force it with executions finish.

Arguments

None.

Options

Flag	Description
--execution-id <uuid>	Required. Execution to book.
--reporting-date <date>	Required. Day to book against, in ISO 8601 (for example, 2026-09-21 or 2026-09-21T10:00:00Z). A date alone books UTC midnight. A time must carry an offset (Z or +hh:mm). The UTC instant must fall between 2019-01-01 and 9999-12-31. An invalid date fails with Result: "ValidationError" before any request.
--project-key <key>	Owning project key. Pass this or --project-id.
--project-id <id>	Owning project ID. Use instead of --project-key. When you pass both, --project-id is used.

Example

uip tm executions set-reporting-date \
  --execution-id a1b2c3d4-0000-0000-0000-000000000002 \
  --reporting-date 2026-09-21 \
  --project-key DEMO

Data shape

{
  "Code": "ExecutionSetReportingDate",
  "Data": {
    "Id": "a1b2c3d4-0000-0000-0000-000000000002",
    "Name": "UAT session 1",
    "Status": "Running",
    "ExecutionType": "Manual",
    "ReportingDate": "2026-09-21T00:00:00.000Z"
  }
}

Data is the execution re-read after the update, with the same fields as get-stats; the example shows a subset. If the re-read fails, Data holds only Id.

uip tm executions delete

Delete a test execution together with the test case logs and log snapshots it owns. The execution then no longer appears in list or list-filtered. Needs the Test Manager execution-delete permission.

Warning:

The server has no state guard: any execution can be deleted, running or not. To stop an automated run's Orchestrator jobs as well, run executions cancel first.

Arguments

None.

Options

Flag	Description
--execution-id <uuid>	Required. Execution to delete.
--project-key <key>	Owning project key. Pass this or --project-id.
--project-id <id>	Owning project ID. Use instead of --project-key. When you pass both, --project-id is used.
-y, --yes	Required. Confirms the irreversible operation. The CLI never prompts; without --yes the command returns Result: "Failure" and exits 1.

Example

uip tm executions delete \
  --execution-id a1b2c3d4-0000-0000-0000-000000000002 \
  --project-key DEMO \
  --yes

Data shape

{
  "Code": "ExecutionDelete",
  "Data": {
    "Id": "a1b2c3d4-0000-0000-0000-000000000002",
    "Result": "Deleted"
  }
}

Exit codes

The standard CI pattern is a three-step pipeline:

1. Launch — uip tm testsets run returns an ExecutionId and exits 0.
2. Block — uip tm wait polls until the execution reaches a terminal state. Exits 0 when finished, 2 on timeout, 1 on failure.
3. Verdict — uip tm report get reads the Passed and Failed counts. Your script fails the build explicitly.

id=$(uip tm testsets run \
  --test-set-key DEMO:10 \
  --execution-type automated \
  --output-filter ExecutionId --output plain)

uip tm wait --execution-id "$id" --project-key DEMO --timeout 1800
code=$?
[ "$code" -eq 2 ] && { echo "timed out" >&2; exit 2; }
[ "$code" -ne 0 ] && { echo "wait failed ($code)" >&2; exit "$code"; }

failed=$(uip tm report get \
  --execution-id "$id" --project-key DEMO --output-filter Failed --output plain)
[ "$failed" -gt 0 ] && { echo "$failed test(s) failed" >&2; exit 1; }
echo "all passed"

For a package already uploaded to Orchestrator, uip tm run performs all three steps in one command and exits non-zero when a test fails.

Related

• testsets run — start an execution.
• run — run every test in an uploaded package, wait, and write a report in one step.
• wait — block until an execution reaches a terminal state.
• report, result, attachment — post-run artifacts.
• testcaselog — start, finish, and inspect individual test case logs; list-assertions turns a failed log into per-assertion detail.

See also

• Test Manager overview
• Exit codes
• Scripting patterns