Launch, finish or terminate a run
const url = 'https://beta-api.plune.ai/v1/runs/example/events';const options = { method: 'POST', headers: {Authorization: 'Bearer <token>', 'Content-Type': 'application/json'}, body: '{"event":"finish"}'};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request POST \ --url https://beta-api.plune.ai/v1/runs/example/events \ --header 'Authorization: Bearer <token>' \ --header 'Content-Type: application/json' \ --data '{ "event": "finish" }'The run lifecycle. launch starts a run saved as scheduled (#1233) and sets its startedAt to now — on a run under way it changes nothing, and a reporter joining a scheduled run by its key starts it too. finish freezes the summary and closes the run to new results; terminate closes it with a reason and can be reopened by joining the same key again. A repeated finish is an idempotent success — the CI step that sends it may itself be retried. Terminating an already finished run is the one refusal: its summary may already have gated a release.
A sharded run (#1601): finish with shardIndex (1-based) and shardsExpected (N) says «shard k of N is done» and does not close the run by itself. The platform keeps the set of distinct indexes that reported, and the run closes — once — when it holds N; the response then is the one a plain finish gives. Fewer than N leaves the run open and answers with the counts. A repeated index counts once, a red shard counts as reported, a shard sent after the close changes nothing, and a different N than the first shard declared is 409 shards_mismatch. Without these two fields finish is exactly what it was.
Authorizations
Section titled “Authorizations ”Parameters
Section titled “ Parameters ”Path Parameters
Section titled “Path Parameters ”Request Body required
Section titled “Request Body required ”object
launch (#1233) starts a scheduled run; on a run under way it changes nothing.
#1601: «shard k of N is done», 1-based, on finish and always with shardsExpected. The same index again counts once; a red shard counts as reported.
#1601: N. The first shard to send it declares it; a different N afterwards is refused with 409 shards_mismatch. The run closes when N distinct indexes have reported; until then finish with a shard leaves it open.
Examples
Close the run and freeze its summary
{ "event": "finish"}Shard 2 of 4 is done (#1601): the run closes when all four have reported
{ "event": "finish", "shardIndex": 2, "shardsExpected": 4}Close it without a summary, and say why
{ "event": "terminate", "reason": "CI job cancelled by a newer push"}Start a run that was saved, not launched (#1233)
{ "event": "launch"}Responses
Section titled “ Responses ”The run, its summary if it just finished, and how many cases the finish detached (configuration.full)
object
object
The value rerun is reached only by joining a terminated run again — it is never requested. scheduled (#1233): saved and not launched yet — launch, or a reporter joining by its key, starts it.
What the run expects to happen. Without it, a crashed shard is indistinguishable from a green run.
object
object
object
Deprecated: not read; configurations are run fields (ADR 0070). Taken and stored as sent.
object
The caller states that expected is everything its source has — the whole suite, not one file or a --grep. When such a run finishes with an empty notRun, every active case that this source (the source of the run’s results) reported before and did not report in this run moves to detached, with the run named as the reason. Manual cases, other sources, in_review and deprecated cases are never touched; a later result on a detached case brings it back to active by itself. Set it only for the run that covers the whole suite (PLUNE_FULL_RUN=1 in the CLI).
Who is to run which case (B8-team T4): testCaseId → userId. Filled at launch by assignment: prefer-assignee from each expected case’s assigneeId at that moment — a snapshot, so a case that changes hands later does not rewrite a run under way. Cases nobody holds are absent. May also be sent as is.
object
object
The commit the run was made from — run.sha in GET /v1/runs/{id}/summary.
The branch it was made on — run.branch in GET /v1/runs/{id}/summary.
The CI run that produced the report — the reporter reads the runner’s own config.metadata.ci.buildHref. Sanitized before it is stored (a credential in a query parameter becomes a marker); set by the shard that opens the run and never changed by one that joins it. The run page links it from GET /v1/runs/{id}/summary.
The tool that reported the run — playwright, or the report format plune run import read — not the machine of the CI; run.runner in GET /v1/runs/{id}/summary.
The plan the run was launched from (D33), when it was — what GET /v1/runs?planId= filters by.
How many cases the plan’s collections selected when the run was launched (#1274); a count taken then, so it does not follow the plan afterwards.
The plan’s collections (filter query strings) as they stood when the run was launched (#1274); a copy, so the run still says what it selected by after the plan is edited or deleted.
What to call this run in a list. The first shard to declare one wins; a shard that arrives later fills a field left empty rather than overwriting.
Where it ran — staging, prod, a preview. Filterable on GET /v1/runs, so two CI matrices read as two histories.
How the run is marked — smoke, nightly, a team name. An empty array is how every mark is removed.
What the run is for, in a person’s words (#1232) — plain text; null when nobody wrote one.
Values of the project’s custom fields (#1764), field id → value. Absent while the run has none. Not configuration, which is the execution plan and is no field.
object
The combinations of configuration values the run was launched with (#1251), in the order of the groups and of their values: Chrome · Windows, Chrome · macOS, Firefox · Windows, Firefox · macOS. Computed by the server from custom when the run is created and frozen; the values of a group cannot change afterwards. Absent for a run launched with none. The one addition: a batch from CI that names a combination the list lacks (configuration of POST /v1/runs/{id}/results) appends it at the end — a number, once given, never changes.
One combination of configuration values (#1251, ADR 0070 §2): a value of each chosen group, the groups in their order. Names are frozen at launch: a rename later changes no past run.
object
object
The group (a field with role: configuration); null with optionId for a value CI named that is not in the list.
The value (an option of the group); null for a value CI named that is not in Settings → Configurations — «not in the list», kept as it was sent.
The name of the group at launch.
The label of the value at launch.
What a run amounted to, frozen at finish. Distinct from RunSummary, which is the list-item shape.
object
One entry per status that occurred, and muted when a muted case failed or broke; an absent key means zero. A failed or broken result of a muted case is counted as muted, not as a failure; a finished run never changes (#1247).
object
counts again, by the priority each result’s case had when the run finished (#1379): { "critical": { "passed": 4, "failed": 1 } }. It is what Analytics counts a finished run under by priority, so a case’s priority changed later moves none of it. Absent from a summary frozen before it was kept.
object
object
Expected and never reported — what keeps a dead shard from looking green.
Cases a retest reset that wait for a new result (#1767): in no count, not in notRun, not in total. Only on a live summary: a run cannot finish while any wait, so a frozen one never has it.
Only for a run with configurations (#1251, ADR 0070 §4): the counts again per combination, in the order of the run’s combinations. notRun and awaitingRetest are by the pair (case, combination): a combination nobody reported has empty counts, total 0 and every expected case in notRun — none of it is counted as skipped. The run’s own notRun is then the cases with a result in no combination, its awaitingRetest the cases waiting in any one.
object
One entry per status that occurred in this combination; an absent key means zero.
object
Expected cases with no current result in this combination.
Cases a retest reset that wait for a new result in this combination; absent for none.
Only for a run with configurations (#1251): the cases that have a result, by where each stands — the worst of its combinations (failed, broken, blocked, muted, passed, skipped): «4 of 120 cases failed». A case in the Bin is not counted (as in /cases?status= and the re-run).
object
Who launched it (B8-team T3): the userId of the session, or of the owner of the token that started or synced it — the first shard to create the run; a joiner is not recorded. null for a run from before names were kept. Resolve it to a name through GET /v1/members.
What a run amounted to, frozen at finish. Distinct from RunSummary, which is the list-item shape.
object
One entry per status that occurred, and muted when a muted case failed or broke; an absent key means zero. A failed or broken result of a muted case is counted as muted, not as a failure; a finished run never changes (#1247).
object
counts again, by the priority each result’s case had when the run finished (#1379): { "critical": { "passed": 4, "failed": 1 } }. It is what Analytics counts a finished run under by priority, so a case’s priority changed later moves none of it. Absent from a summary frozen before it was kept.
object
object
Expected and never reported — what keeps a dead shard from looking green.
Cases a retest reset that wait for a new result (#1767): in no count, not in notRun, not in total. Only on a live summary: a run cannot finish while any wait, so a frozen one never has it.
Only for a run with configurations (#1251, ADR 0070 §4): the counts again per combination, in the order of the run’s combinations. notRun and awaitingRetest are by the pair (case, combination): a combination nobody reported has empty counts, total 0 and every expected case in notRun — none of it is counted as skipped. The run’s own notRun is then the cases with a result in no combination, its awaitingRetest the cases waiting in any one.
object
One entry per status that occurred in this combination; an absent key means zero.
object
Expected cases with no current result in this combination.
Cases a retest reset that wait for a new result in this combination; absent for none.
Only for a run with configurations (#1251): the cases that have a result, by where each stands — the worst of its combinations (failed, broken, blocked, muted, passed, skipped): «4 of 120 cases failed». A case in the Bin is not counted (as in /cases?status= and the re-run).
object
Cases moved to detached by this finish: those the run’s source reported before and this full run did not. 0 unless the run declared configuration.full and reported everything it expected.
#1601: distinct shards that reported, when the request carried shardIndex.
#1601: N, when the request carried shardIndex.
Example
{ "run": { "id": "6f1c2b3a-0000-4000-8000-0000000000d1", "projectId": "u-shop::default", "kind": "automated", "externalKey": "gh-35003177826", "statusEvent": "finished", "configuration": { "full": true, "expected": [ { "testCaseId": "6f1c2b3a-0000-4000-8000-0000000000c1" }, { "externalKey": { "kind": "path-title", "value": "e2e/checkout.spec.ts > Checkout — coupon applied" } } ] }, "meta": { "sha": "3e31591", "branch": "master", "ciUrl": "https://github.com/plune-ai/plune/actions/runs/35003177826", "runner": "playwright" }, "startedAt": "2026-09-16T09:12:04.151Z", "finishedAt": "2026-09-16T09:12:09.082Z", "terminateReason": null, "summary": { "total": 2, "counts": { "passed": 1, "failed": 1 }, "notRun": [] }, "title": "plune · 2026-09-16 09:12 · ci", "environment": "staging", "labels": [ "plune", "vitest", "ci" ], "description": null, "createdBy": "u-shop" }, "summary": { "total": 2, "counts": { "passed": 1, "failed": 1 }, "notRun": [] }, "detached": 0}Not a known event
object
Example generated
{ "error": "example"}No / invalid token or session
Not found or not yours
object
Example generated
{ "error": "example"}The event does not apply from this state (the body names what does), or shardsExpected differs from the N the run holds (shards_mismatch, naming it), or a retested case still waits for its new result (retest_pending, with awaitingRetest: the case ids; #1767)
object
What WOULD apply from this state. A CI script needs this to stop retrying.
object
The N the run already holds.
Example
{ "code": "shards_mismatch"}Rate limited
The API could not take the request now, and nothing was stored: code pool_overloaded — every database connection is busy and the queue for one is long (refused at once, or the wait for a connection ran out); statement_timeout — Postgres cancelled a statement that ran for 60 s. Retry-After carries the seconds to wait (a few of jitter on top, so that what was refused together does not come back together). The CLI waits that long and sends the batch again, then falls back to its file.
object
Example
{ "error": "the server is busy — the database has no free connection; retry after the time in Retry-After", "code": "pool_overloaded"}Headers
Section titled “Headers ”Seconds to wait before the same request is sent again; grows with the length of the queue for a connection