checkly 0.0.0-canary.58c867e

package/dist/ai-context/skills-command/references/investigate-alerting.md

@@ -0,0 +1,212 @@
+# Investigating Alerting Behavior
+
+Use this read-only flow when a user asks which alert settings actually apply to
+a deployed check, especially when check-local, group, global, and alert-channel
+settings may interact.
+
+Table output is insufficient for this scenario. Use JSON or raw API evidence
+whenever available because human tables can omit `alertSettings`,
+`useGlobalAlertSettings`, `alertChannelSubscriptions`, `groupId`, `muted`,
+`activated`, `retryStrategy`, and `doubleCheck`.
+
+Only use read-only commands. Do not deploy, update, delete, trigger checks,
+start test runs, run RCA, mutate incidents, or change alert channels. When using
+`checkly api`, only use `GET` requests; do not pass write methods, `-F` fields,
+or request bodies.
+
+Keep the investigation bounded. Use the commands and endpoints listed in this
+reference, plus exact endpoints returned by those commands if they are needed to
+follow a concrete ID. Do not guess multiple possible account/global alerting
+endpoints. If a listed command or endpoint does not expose a field, report that
+the field was unavailable in the inspected output instead of probing variants.
+
+## Recommended Read-Only Command Sequence
+
+Start by identifying one concrete check. If the user gave a name instead of an
+ID, search and inspect the JSON list output before choosing:
+
+```bash
+checkly checks list --output json --limit 100
+checkly checks list --output json --limit 100 --search "<check-name>"
+```
+
+Then inspect the selected check with structured output:
+
+```bash
+checkly checks get <check-id> --output json
+checkly api /v1/checks/<check-id>
+```
+
+Use the CLI detail output for context only after you have captured JSON/API
+evidence:
+
+```bash
+checkly checks get <check-id>
+```
+
+Inspect alert channels as structured evidence. The list helps identify channel
+IDs and subscription scopes. Only call `get` for channel IDs referenced by the
+selected check or matching group subscriptions, or for a user-named channel you
+must verify. Do not fetch every channel when there are no relevant
+subscriptions:
+
+```bash
+checkly alert-channels list --output json --limit 100
+checkly alert-channels get <alert-channel-id> --output json
+```
+
+If the check has a `groupId`, fetch groups once and locate the matching group.
+Use the raw API because group override fields may not have a dedicated CLI
+command:
+
+```bash
+checkly api /v1/check-groups
+```
+
+If the selected check has no `groupId`, or if
+`checks list --output json --limit 100` returns no checks with `groupId`, stop
+group override investigation. Say that group override analysis is unavailable
+from the current evidence and continue with check, global-selection, and
+alert-channel evidence. Do not invent group behavior and do not keep looking for
+alternative group endpoints.
+
+This reference does not define a dedicated account/global alert-settings
+endpoint. When `useGlobalAlertSettings: true` is the only account/global signal,
+say that global alert settings are selected but their policy details were not
+available in the inspected output. Do not probe guessed endpoints such as
+account-settings, account/settings, check-alerts, or alert-notifications just to
+fill that gap.
+
+## Fields To Inspect
+
+For the selected check, capture and explain:
+
+- `activated` - whether the check is scheduled to run.
+- `muted` - whether check-level alert notifications are suppressed.
+- `groupId` - whether group settings may affect the check.
+- `alertSettings` - check-local escalation policy evidence.
+- `useGlobalAlertSettings` - whether the check selects account/global alert
+  settings instead of a local policy.
+- `alertChannelSubscriptions` - check-local or group-scoped channel bindings,
+  including each subscription's `activated`, `checkId`, `groupId`, and channel
+  ID.
+- `retryStrategy` and `doubleCheck` - retry or double-check behavior that can
+  delay or change when a failure becomes alert-worthy.
+
+For a matching group, capture and explain:
+
+- `activated` and `muted` - whether the group can stop runs or suppress alerts.
+- `alertSettings` and `useGlobalAlertSettings` - whether the group forces a
+  custom or global escalation policy for grouped checks.
+- `alertChannelSubscriptions`, or alert-channel subscriptions whose `groupId`
+  matches the group - which group-scoped channels are active.
+- `retryStrategy` and `doubleCheck` - group-level retry behavior when present.
+
+For alert channels, capture and explain:
+
+- channel `id`, `type`, name/config label, and whether the channel itself is
+  active if the API exposes that field.
+- subscription scope: check-local (`checkId` matches the check and `groupId` is
+  empty), group-scoped (`groupId` matches the check's group), or unrelated.
+- subscription `activated` status. Inactive subscriptions are evidence of
+  configuration, not active alert delivery.
+
+## Effective Alerting Decision Tree
+
+Apply this tree from confirmed evidence only:
+
+1. Check run and notification gates:
+   - If the check has `activated: false`, report that it is inactive and should
+     not produce scheduled alerts unless other output proves otherwise.
+   - If the check has `muted: true`, report that check-level notifications are
+     suppressed.
+   - If a fetched group for this check has `activated: false`, report that the
+     group stops grouped checks from running when the API output confirms it.
+   - If a fetched group has `muted: true`, report that group-level muting
+     suppresses alerts for grouped checks.
+2. Group override status:
+   - If the check has no `groupId`, group overrides do not apply to this check.
+   - If no grouped checks are present in the inspected list output, group
+     override analysis is unavailable from current evidence.
+   - If the check has a `groupId`, inspect the matching group before deciding
+     effective escalation or group channel behavior.
+   - If group `useGlobalAlertSettings` is `false` and group `alertSettings` is
+     present, report the group escalation policy as the effective policy for
+     the grouped check.
+   - If group `useGlobalAlertSettings` is `true`, report that the group selects
+     account/global escalation. Do not describe the global policy unless another
+     output shows its values.
+   - If group `useGlobalAlertSettings` is missing, `null`, or `undefined`, and
+     no group `alertSettings` is present, do not claim a group escalation
+     override. Continue to check-local evidence.
+   - If group-scoped alert channel subscriptions are present and active, report
+     them as group-scoped channels. If group channels exist but group policy
+     fields are unavailable, say whether channel applicability is unavailable
+     rather than assuming they apply.
+3. Check-local escalation:
+   - If check `useGlobalAlertSettings` is `false` and check `alertSettings` is
+     present, report the check-local escalation policy as effective unless a
+     confirmed group override above supersedes it.
+   - If check `useGlobalAlertSettings` is `true`, report that the check selects
+     account/global escalation unless a confirmed group override above supersedes
+     it.
+   - If check `alertSettings` and `useGlobalAlertSettings` are absent or
+     contradictory, report the escalation source as unavailable instead of
+     inferring defaults.
+4. Account/global settings:
+   - Treat account/global settings as known only when CLI or API output exposes
+     their values.
+   - Do not try multiple guessed account/global alerting endpoints. Use a
+     documented endpoint only when this reference, CLI output, or the API
+     reference gives the exact path. If that one documented request fails or does
+     not include the needed fields, report the values as unavailable.
+   - If output only shows `useGlobalAlertSettings: true`, say "global alert
+     settings are selected, but their policy details were not available in the
+     inspected CLI/API output."
+5. Retry and double-check behavior:
+   - If `retryStrategy` is present, explain how it affects when alerts can fire
+     based on the returned fields.
+   - If `doubleCheck` is present and `retryStrategy` is absent, explain the
+     double-check behavior as returned.
+   - If neither field is available, say retry or double-check behavior was not
+     available in the inspected output.
+
+## Response Template
+
+Use this structure when reporting back:
+
+```markdown
+## Alerting evidence for <check-name> (<check-id>)
+
+### Confirmed evidence
+- Check state: activated=<value>, muted=<value>, groupId=<value>
+- Check escalation fields: useGlobalAlertSettings=<value>, alertSettings=<summary or null>
+- Retry fields: retryStrategy=<summary or unavailable>, doubleCheck=<value or unavailable>
+- Sources: <commands used>
+
+### Effective escalation policy
+<State the effective escalation policy source: group custom policy, group-selected
+global policy, check-local policy, check-selected global policy, or unavailable.
+Quote only values visible in JSON/API output.>
+
+### Alert channels
+- Check-local channels: <active channel IDs/types/names, inactive subscriptions, or none>
+- Group-scoped channels: <active channel IDs/types/names, inactive subscriptions, unavailable, or not applicable>
+- Unrelated channels ignored: <short summary if useful>
+
+### Group override status
+<No groupId / no grouped checks found / matching group inspected with fields /
+matching group unavailable. Explain whether group settings or channels override
+or affect the check based only on confirmed fields.>
+
+### Unavailable evidence
+- Account/global alert policy details: <known values or unavailable>
+- Missing fields/endpoints: <fields not present or API data not returned>
+
+### Recommended next read-only checks
+- <Only include GET/list commands that would close evidence gaps, such as
+  `checkly api /v1/checks/<check-id>` or
+  `checkly alert-channels get <alert-channel-id> --output json` for a channel
+  ID referenced by a relevant subscription. Do not recommend guessed
+  account/global alerting endpoints.>
+```

package/dist/ai-context/skills-command/references/investigate-checks.md

@@ -0,0 +1,156 @@
+# Inspecting Checks
+
+List and inspect deployed checks in your Checkly account.
+
+## List checks
+
+```bash
+npx checkly checks list
+npx checkly checks list --tag production --type PLAYWRIGHT
+npx checkly checks list --status failing
+npx checkly checks list --search "Homepage" --output json
+```
+
+Flags:
+- `-t, --tag <tag>` — filter by tag (repeat for multiple)
+- `--type <type>` — filter by check type (`API`, `BROWSER`, `HEARTBEAT`, `MULTI_STEP`, `PLAYWRIGHT`, `TCP`, `ICMP`, `DNS`, `URL`, `AGENTIC`)
+- `-s, --search <name>` — filter by name (case-insensitive partial match)
+- `--status <status>` — filter by current status: `passing`, `failing`, or `degraded`
+- `-l, --limit <n>` — max checks to return (1-100, default 25)
+- `-p, --page <n>` — page number
+- `-o, --output <format>` — `table` (default), `json`, or `md`
+
+## Get check details
+
+```bash
+npx checkly checks get <check-id>
+npx checkly checks get <check-id> --output json
+npx checkly checks get <check-id> --stats-range last7Days --group-by location
+```
+
+Shows check configuration, recent results, error groups, and analytics stats.
+
+Flags:
+- `-r, --result <result-id>` — drill into a specific result (see below)
+- `--include-attempts` — with `--result`, also list the individual retry attempts for that result (see below)
+- `-e, --error-group <error-group-id>` — show full details for a specific error group
+- `--results-limit <n>` — number of recent results to show (default 10)
+- `--results-cursor <cursor>` — paginate results using the cursor from previous output
+- `--stats-range <range>` — analytics range: `last24Hours` (default), `last7Days`, `last30Days`, `thisWeek`, `thisMonth`, `lastWeek`, `lastMonth`
+- `--group-by <dimension>` — group stats by `location` or `statusCode`
+- `--metrics <list>` — comma-separated list of metrics to show (overrides defaults)
+- `--filter-status <status>` — only include runs with this status in stats: `success` or `failure`
+- `-o, --output <format>` — `detail` (default), `json`, or `md`
+
+**Important:** Look for `errorGroups`, `rootCause` or `RCA` to investigate a root cause. If available, let the user know that Rocky AI (Checkly's AI agent) evaluated the issue already and reuse all available information.
+
+### View a specific check result
+
+```bash
+npx checkly checks get <check-id> --result <result-id>
+npx checkly checks get <check-id> --result <result-id> --output json
+```
+
+### View retry attempts for a result
+
+When a check has retries enabled, a single run produces one `FINAL` result plus
+one `ATTEMPT` result for each earlier failed try (all sharing a `sequenceId`).
+By default only the `FINAL` result is shown. Add `--include-attempts` to list the
+full retry sequence — attempt number, status, location, duration, and a short
+error summary:
+
+```bash
+npx checkly checks get <check-id> --result <result-id> --include-attempts
+npx checkly checks get <check-id> --result <result-id> --include-attempts --output json
+```
+
+With `--include-attempts --output json`, the command returns a stable envelope:
+
+```json
+{
+  "result": {},
+  "attempts": []
+}
+```
+
+Use the `attempts` array to inspect intermediate retry failures. Use the `result`
+object for the requested result row.
+
+### List or download result assets
+
+Result detail output summarizes available screenshots, traces, and videos when
+present. Use the dedicated asset manifest commands to inspect exact asset names
+and download files:
+
+```bash
+npx checkly assets list --check-id <check-id> --result-id <result-id>
+npx checkly assets list --check-id <check-id> --result-id <result-id> --type trace --view tree
+npx checkly assets list --check-id <check-id> --result-id <result-id> --output json
+npx checkly assets download --check-id <check-id> --result-id <result-id> --asset "<Asset>"
+npx checkly assets download --check-id <check-id> --result-id <result-id> --type all --dir ./checkly-assets
+```
+
+Run `assets list` first to discover available files. The default table output
+has an `Asset` column; copy that value into `--asset` for single-file downloads.
+
+Flags:
+- `--type <type>` - filter/select by `log`, `trace`, `video`, `screenshot`, `pcap`, `report`, `file`, or `all`.
+- `--asset <value>` - exact Asset/Name value or glob. Prefer copying the `Asset` value from the default table output before downloading a single file.
+- `--dir <path>` - destination directory for downloads; defaults under `./checkly-assets/`.
+- `--force` / `--skip-existing` - overwrite or preserve existing files.
+
+`assets list --output json` uses a stable list envelope:
+
+```json
+{
+  "data": [],
+  "pagination": {
+    "length": 0
+  }
+}
+```
+
+`assets download` requires `--type` or `--asset` unless the manifest is a single
+archive bundle. Archive entries download as their containing archive; filters
+narrow the manifest list, not the archive bytes.
+
+Do not invent asset names or assume every result has the same artifact set. Some
+results have screenshots only, some have traces or videos, and some have no
+downloadable assets.
+
+### View an error group
+
+```bash
+npx checkly checks get <check-id> --error-group <error-group-id>
+```
+
+## Check analytics and stats
+
+```bash
+npx checkly checks stats
+npx checkly checks stats --range last7Days --tag production
+npx checkly checks stats <check-id-1> <check-id-2>
+npx checkly checks stats --output json
+```
+
+Shows availability, response times, error counts, and other metrics for your checks.
+
+Flags:
+- `-r, --range <range>` — time range: `last24Hours` (default), `last7Days`, `thisWeek`, `lastWeek`, `lastMonth`
+- `-t, --tag <tag>` — filter by tag (repeat for multiple)
+- `--type <type>` — filter by check type
+- `-s, --search <name>` — filter by name
+- `-l, --limit <n>` — max checks to return (1-100, default 25)
+- `-p, --page <n>` — page number
+- `-o, --output <format>` — `table` (default), `json`, or `md`
+
+Pass one or more check IDs as positional arguments to get stats for specific checks only.
+
+## Trigger checks
+
+```bash
+npx checkly trigger --tags production
+npx checkly trigger --tags critical,api
+```
+
+Triggers existing deployed checks by tag. Useful for on-demand verification.

package/dist/ai-context/skills-command/references/investigate-test-sessions.md

@@ -0,0 +1,165 @@
+# Investigating Test Sessions
+
+Use this flow when a user asks you to run a session, inspect recorded test-session results, investigate test-session error groups, run root cause analysis, or retrieve result logs, traces, videos, screenshots, and other assets.
+
+Read-only inspection commands execute immediately. `rca run` starts a new analysis, but it does not mutate checks or monitors.
+
+## Run or trigger a recorded session
+
+`checkly test`, `checkly trigger`, and `checkly pw-test` record results as a test session by default. Use `--no-record` only when the user explicitly does not want a recorded session.
+
+```bash
+npx checkly test --detach --test-session-name "Checkout regression"
+npx checkly test --record --detach --test-session-name "Checkout regression"
+npx checkly trigger --detach --tags production --test-session-name "Production smoke"
+npx checkly pw-test --detach --test-session-name "Playwright suite"
+```
+
+For agent workflows, prefer `--detach` when starting recorded sessions. The command schedules the session, prints the `Test session ID`, and exits without waiting for completion. Inspect the session with `npx checkly test-sessions get <test-session-id> --watch` instead of relying on Checkly UI links.
+
+Useful flags:
+- `--location <region>` or `--private-location <slug>` - choose where checks run.
+- `-e, --env KEY=value` or `--env-file <path>` - pass runtime environment variables.
+- `--timeout <seconds>` - wait for session completion before the command exits; ignored when `--detach` exits after scheduling.
+- `-d, --detach` - start the session in the cloud, print the test session ID, and exit immediately; preferred for agents starting recorded sessions.
+
+Do not combine `--detach` with file reporters such as `--reporter json` or `--reporter github`. Detached runs exit before results are available, so no result report can be written. After scheduling with `--detach`, use `test-sessions get --output json` for machine-readable session details.
+
+If the command output includes a test session ID or link, use the ID directly with `test-sessions get`.
+
+## Find a test session
+
+```bash
+npx checkly test-sessions list
+npx checkly test-sessions list --status failed --limit 10
+npx checkly test-sessions list --branch main --provider github
+npx checkly test-sessions list --search "checkout"
+npx checkly test-sessions list --error-group <test-session-error-group-id>
+npx checkly test-sessions list --output json
+```
+
+Flags:
+- `-l, --limit <n>` - number of sessions to return (1-100, default 20).
+- `--cursor <nextId>` - fetch the next cursor page.
+- `--from <date>` / `--to <date>` - filter by ISO date or Unix timestamp in seconds.
+- `--status <status>` - `running`, `failed`, `passed`, or `cancelled`; repeat or comma-separate.
+- `--provider <provider>` - `github`, `vercel`, `api`, `trigger`, or `pw_reporter`; repeat or comma-separate.
+- `--branch <name>` - filter by Git branch; repeat or comma-separate.
+- `--user <id>` and `--no-users` - filter by commit owner/invoking user, or include sessions without either.
+- `-s, --search <text>` - search test-session text fields.
+- `--error-group <id>` - find sessions that include a specific test-session error group.
+- `-o, --output <format>` - `table` (default), `json`, or `md`.
+
+JSON output uses the stable list envelope:
+
+```json
+{
+  "data": [],
+  "pagination": {
+    "nextId": null,
+    "length": 0
+  }
+}
+```
+
+## Inspect a test session
+
+```bash
+npx checkly test-sessions get <test-session-id>
+npx checkly test-sessions get <test-session-id> --watch
+npx checkly test-sessions get <test-session-id> --output json
+npx checkly test-sessions get <test-session-id> --error-groups-limit 20
+```
+
+Flags:
+- `-w, --watch` - wait for a running session to complete before rendering.
+- `--error-groups-limit <n>` - number of error group IDs to show in detail output (default 5).
+- `-o, --output <format>` - `detail` (default), `json`, or `md`.
+
+The detail view shows the session status, metadata, result rows, test-session result IDs, check IDs when available, and test-session error group IDs. Prefer `--watch` before investigating failures so you do not act on partial results.
+
+Use `--output json` when you need exact fields, result links, check IDs, or test-session result IDs. For downloadable logs, traces, videos, screenshots, reports, and files, use `checkly assets list` and `checkly assets download` with the test session ID and result ID.
+
+## Inspect a test-session error group
+
+Use only error group IDs shown by `test-sessions get`. Test-session error groups are separate from check error groups, so do not pass them to `checks get --error-group`.
+
+```bash
+npx checkly test-sessions get <test-session-id> --error-group <test-session-error-group-id>
+npx checkly test-sessions get <test-session-id> --error-group <test-session-error-group-id> --full-error
+npx checkly test-sessions get <test-session-id> --error-group <test-session-error-group-id> --output json
+```
+
+Flags:
+- `--full-error` - print the complete raw error for the selected test-session error group.
+- `-w, --watch` - wait for session completion before validating and fetching the error group.
+- `-o, --output <format>` - `detail` (default), `json`, or `md`.
+
+Look for `rootCauseAnalyses` in JSON output. If one already exists, reuse it before starting a new RCA.
+
+## Run root cause analysis
+
+For test-session error groups, use `--test-session-error-group` (short alias `-te`). For regular check error groups, use `--error-group` (short alias `-e`).
+
+```bash
+npx checkly rca run --test-session-error-group <test-session-error-group-id> --watch
+npx checkly rca run -te <test-session-error-group-id> --user-context "Started after checkout deploy" --watch
+npx checkly rca get <rca-id> --watch
+```
+
+Flags:
+- `--user-context <text>` - add concise context that can improve the analysis.
+- `-w, --watch` - wait for completion and print the analysis.
+- `-o, --output <format>` - `detail` (default), `json`, or `md`; watch mode is only supported with detail output.
+
+If RCA is unavailable because of plan or entitlement limits, run `npx checkly account plan --output json` and report the relevant entitlement or upgrade URL.
+
+## Retrieve result assets
+
+Use the asset manifest commands for recorded test-session result files. Start
+from `test-sessions get` to identify the `testSessionResultId` (and `checkId`
+when available) for the row you want to inspect.
+
+```bash
+npx checkly test-sessions get <test-session-id> --output json
+npx checkly assets list --test-session-id <test-session-id> --result-id <test-session-result-id>
+npx checkly assets list --test-session-id <test-session-id> --result-id <test-session-result-id> --type trace --view tree
+npx checkly assets list --test-session-id <test-session-id> --result-id <test-session-result-id> --output json
+npx checkly assets download --test-session-id <test-session-id> --result-id <test-session-result-id> --asset "<Asset>"
+npx checkly assets download --test-session-id <test-session-id> --result-id <test-session-result-id> --type all --dir ./checkly-assets
+```
+
+Run `assets list` first to discover available files. The default table output
+has an `Asset` column; copy that value into `--asset` for single-file downloads.
+
+Flags:
+- `--type <type>` - filter/select by `log`, `trace`, `video`, `screenshot`, `pcap`, `report`, `file`, or `all`.
+- `--asset <value>` - exact Asset/Name value or glob. Prefer copying the `Asset` value from `assets list --view table` for single-file downloads.
+- `--dir <path>` - destination directory for downloads; defaults under `./checkly-assets/`.
+- `--force` / `--skip-existing` - overwrite or preserve existing files.
+
+`assets list --output json` uses a stable list envelope:
+
+```json
+{
+  "data": [],
+  "pagination": {
+    "length": 0
+  }
+}
+```
+
+`assets download` requires `--type` or `--asset` unless the manifest is a single
+archive bundle. Archive entries download as their containing archive; filters
+narrow the manifest list, not the archive bytes.
+
+If you also need the scheduled check result view for the same row, and the row
+has a `checkId`, use:
+
+```bash
+npx checkly checks get <check-id> --result <test-session-result-id>
+```
+
+Do not invent asset names or assume every result has the same artifact set. Some
+results have screenshots only, some have traces or videos, and some have no
+downloadable assets.

package/dist/ai-context/skills-command/references/investigate.md

@@ -0,0 +1,18 @@
+# Investigating Check Status and Errors
+
+Access check status, analyze failures, and investigate errors across your Checkly account.
+
+Read-only commands execute immediately without confirmation.
+
+## Available Commands
+
+Parse and read further reference documentation when tasked with investigating any of the following:
+
+### `npx checkly skills investigate checks`
+Inspect checks (`checks list`, `checks get`), retry attempts, result assets, and trigger on-demand runs
+
+### `npx checkly skills investigate alerting`
+Inspect effective alerting behavior for a check across check-local, group, global, and alert-channel evidence
+
+### `npx checkly skills investigate test-sessions`
+Run and inspect recorded test sessions, drill into test-session error groups, run RCA, and list/download result assets

package/dist/ai-context/skills-command/references/manage-account-members.md

@@ -0,0 +1,82 @@
+# Account Members
+
+List active account members and pending or expired account invites. Update active member roles and delete active members.
+
+## Usage
+
+```bash
+npx checkly members
+npx checkly members --output json
+npx checkly members --search alice
+npx checkly members --type invite --status pending
+npx checkly members --role admin
+npx checkly members --limit 25
+npx checkly members --hide-id
+npx checkly members update alice@example.com --role read_run
+npx checkly members update <user-id> --role admin --id --force
+npx checkly members delete alice@example.com --force
+```
+
+Flags:
+- `--search <term>` — match member names, member emails, and invite emails.
+- `--type <type>` — `member` or `invite` (case-insensitive).
+- `--role <role>` — `owner`, `admin`, `read_write`, `read_run`, or `read_only` (case-insensitive).
+- `--status <status>` — `active`, `pending`, or `expired` (case-insensitive).
+- `-l, --limit <n>` — number of rows to return, from 1 to 100.
+- `--next-id <cursor>` — cursor for the next page. Requires `--limit`.
+- `-o, --output <format>` — `table` (default), `json`, or `md`.
+- `--hide-id` — hide member and invite IDs in table output.
+
+Role update:
+- `checkly members update <member> --role <role>` updates an active account member role.
+- `<member>` can be an email address or user ID. Values containing `@` are resolved as exact member emails by default; other values are treated as user IDs.
+- Use `--email` or `--id` to force how `<member>` is interpreted.
+- Valid update roles are `admin`, `read_write`, `read_run`, and `read_only` (case-insensitive).
+- `owner` cannot be set through this command.
+- This mutation requires confirmation. In non-interactive mode, rerun with `--force` after reviewing the confirmation preview.
+
+Delete member:
+- `checkly members delete <member>` removes an active account member.
+- `<member>` can be an email address or user ID. Values containing `@` are resolved as exact member emails by default; other values are treated as user IDs.
+- Use `--email` or `--id` to force how `<member>` is interpreted.
+- This destructive mutation requires confirmation. In non-interactive mode, rerun with `--force` after reviewing the confirmation preview.
+- Pending invite cancellation is not handled by this command.
+
+## JSON response shape
+
+```json
+{
+  "members": [
+    {
+      "type": "member",
+      "accountId": "11111111-1111-1111-1111-111111111111",
+      "userId": "22222222-2222-2222-2222-222222222222",
+      "name": "Owner User",
+      "email": "owner@example.com",
+      "role": "OWNER",
+      "status": "ACTIVE",
+      "createdAt": "2026-01-01T00:00:00.000Z",
+      "updatedAt": "2026-01-02T00:00:00.000Z",
+      "isSupportMembership": false,
+      "ssoEnabled": false,
+      "mfaEnabled": true
+    },
+    {
+      "type": "invite",
+      "id": "33333333-3333-3333-3333-333333333333",
+      "accountId": "11111111-1111-1111-1111-111111111111",
+      "email": "pending@example.com",
+      "role": "READ_ONLY",
+      "status": "PENDING",
+      "inviterEmail": "owner@example.com",
+      "createdAt": "2026-01-03T00:00:00.000Z",
+      "updatedAt": "2026-01-03T00:00:00.000Z",
+      "expiresAt": "2026-02-03T00:00:00.000Z"
+    }
+  ],
+  "length": 2,
+  "nextId": null
+}
+```
+
+Member roles are returned as `OWNER`, `ADMIN`, `READ_WRITE`, `READ_RUN`, or `READ_ONLY`. Invite roles exclude `OWNER`. Invite statuses are returned as `PENDING` or `EXPIRED`.