Skip to main content

Documentation Index

Fetch the complete documentation index at: https://checklyhq.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

Cancellation lets you stop an in-progress Playwright Check Suite run. Cancelled results are flagged with isCancelled: true, do not trigger alerts, and are excluded from availability and performance metrics. A session that contains at least one cancelled run ends in a terminal CANCELLED status.

​
What you can cancel

You can cancel two kinds of sessions, and the behaviour differs: Check sessions — created by the UI “Schedule now” button and checkly deploy. A check session is one execution of a single Playwright Check Suite, fanned out across the locations you configured. Cancelling the session stops every in-progress run; cancelling a single run leaves the rest of the session going. Test sessions — created by checkly test, checkly trigger, and checkly pw-test, which all record by default. A test session can contain multiple checks of different types. Cancelling the test session stops only the Playwright Check Suite runs inside it; any URL, API, Browser, Multistep, Heartbeat, TCP, DNS, or ICMP runs in the same session continue until they finish normally. You can also cancel a single Playwright run within the session.
Only Playwright Check Suite runs are cancellable. Other check types cannot be cancelled, even when they appear inside a test session alongside Playwright runs. Scheduled runs are also excluded; cancellation is for user-initiated runs only.

​
How to cancel

On a check session or test session page, click Cancel session in the header to stop the whole session. To stop just a single run, use the cancel button on its row.

​
What happens after a run is cancelled

1

The runner stops execution

The runner receives the cancellation signal, aborts the in-flight Playwright run, and reports the result back to Checkly.
2

The result is marked cancelled

Each cancelled run’s result has isCancelled: true. Once the session has stopped (any remaining non-Playwright checks finish normally), the session’s status becomes CANCELLED because at least one of its runs was cancelled.
3

No alert is sent

Cancelled runs never produce failure or recovery alerts, regardless of your alert settings. See Alert configuration.
4

Metrics ignore the run

Availability, response time percentiles, and success ratios exclude cancelled runs. Your check status does not change. Public and private dashboards omit cancelled runs from their summary counts.
5

Automated incidents are not triggered

Because no alert is sent and the check status does not change, automated incidents are not opened from a cancelled run.

​
API versioning

Cancellation introduces two API additions: a new CANCELLED value on the check-session status enum, and a new isCancelled boolean on individual check results. The isCancelled flag is additive and ships on every check-result and check-session response without a version bump. The status enum change is breaking for clients that switch on status values exhaustively, so the new CANCELLED value is only returned by the v2 check-session endpoints; v1 maps cancelled sessions to TIMED_OUT in status so existing clients continue to work unchanged.
​
v1 check sessions
deprecated
POST /v1/check-sessions/trigger, GET /v1/check-sessions/{checkSessionId}, and GET /v1/check-sessions/{checkSessionId}/completion report cancelled sessions as TIMED_OUT in status rather than CANCELLED. Per-result objects still include isCancelled, so individual cancelled runs remain identifiable.
​
v2 check sessions
recommended
POST /v2/check-sessions/trigger, GET /v2/check-sessions/{checkSessionId}, and GET /v2/check-sessions/{checkSessionId}/completion return CANCELLED in status for cancelled sessions. Response shape is otherwise the same as v1.
​
check results
additive change
GET /v1/check-results/{checkId}/{checkResultId} and the list endpoints include isCancelled on every result.
​
cancel action
new endpoints
POST /v1/check-sessions/{checkSessionId}/cancel and POST /v1/test-sessions/{testSessionId}/cancel are the action endpoints. Each takes the session ID in the path and an optional sequenceId array in the body.
If you build automation against check sessions and need to distinguish cancelled sessions from genuine timeouts at the session level, switch to the v2 endpoints. Otherwise, the isCancelled flag on per-result objects is available in both versions.