version: "1.0.1" name: checkly description: Set up, create, test and manage monitoring checks using the Checkly CLI. Use when working with API Checks, Browser Checks, URL Monitors, ICMP Monitors, Playwright Check Suites, Heartbeat Monitors, Alert Channels, Dashboards, or Status Pages. Access Checkly account plan, entitlements, feature limits, members, and pending invites. Includes generic API pass-through (checkly api) for endpoints without dedicated commands. allowed-tools: Bash(npx checkly:), Bash(npm install:) metadata: author: checkly

Checkly

CLI or MCP? Establish your path first

This skill drives the npx checkly CLI in a shell. The Checkly MCP server covers a subset — live account work: check status and results, test sessions, root cause analyses (RCA), triggering existing checks, and incidents. Only the CLI can author, test, and deploy Monitoring as Code.

Before your first command that talks to the Checkly API, establish your path:

1. No shell access (chat-only session): stop following this skill and use the Checkly MCP tools if they're connected; if not, tell the user you need either a shell or the Checkly MCP server to work with Checkly.
2. Shell access: run npx checkly whoami once.

• Succeeds → use the CLI for everything and keep following this skill, even when Checkly MCP tools are also connected.
• Fails with an auth error → route by task:
• Authoring, testing, or deploying checks: MCP cannot do this. Ask the user to authenticate — npx checkly login, or CHECKLY_API_KEY + CHECKLY_ACCOUNT_ID in the environment or .env — then re-run whoami. Don't work around a missing login.
• Live account work (status, results, test sessions, RCA, triggering, incidents): fall back to the Checkly MCP tools if they're connected. Call the MCP whoami tool first and tell the user which account you're operating on. If MCP isn't connected either, ask the user to authenticate the CLI as above.

Two rules that survive any fallback:

• Account parity. CLI auth and the MCP session can point at different accounts — users often belong to several. Never mix CLI and MCP results in one task without confirming both use the same account ID, and always name the account after a fallback.
• Writes still need confirmation. The CLI's confirmation protocol (below) does not travel with you to MCP. If you fall back for a write action (e.g. creating an incident), present the intended change and get the user's approval before calling the tool.

Always load the current action list first

Required: Before answering any Checkly question, run npx checkly skills to get the current and up-to-date action list. Do not rely on memory or prior context — the CLI is the source of truth and actions might change between releases. npx checkly skills runs locally — it needs no authentication or API access, so it works before you've established your path above.

Then run npx checkly skills <action> to load up-to-date details for the action you need.

Use npx checkly skills install to install this skill into your project (supports Claude Code, Cursor, Codex and more).

For recorded test-session investigations, run npx checkly skills investigate test-sessions.

Progressive Disclosure via npx checkly skills

The skill is structured for efficient context usage:

1. Metadata (~80 tokens): Name and description in frontmatter
2. Core Instructions (~1K tokens): Main SKILL.md content with links to reference commands
3. Reference Commands (loaded on demand): Detailed construct documentation with examples

Agents load what they need for each task.

Plan Awareness

Before configuring checks, run npx checkly account plan --output json to see what features, locations, and limits are available on the current plan. A disabled entitlement may include an upgradeUrl for self-service checkout or enterprise contact sales. Share it only when present; otherwise the entitlement is unavailable.

Run npx checkly skills manage for the full reference.

Confirmation Protocol

Write commands (e.g. incidents create, deploy, destroy) return exit code 2 with a confirmation_required JSON envelope instead of executing. Always present the `changes` to the user and wait for approval before running the `confirmCommand`. This applies to every write command individually — updates and resolutions need confirmation too, not just the initial create.

The confirmCommand is the approved command, ready to run verbatim: it repeats the flags you passed and already ends in --force. Run it as-is once the user approves — don't add --force to a command yourself, and don't add flags the user didn't ask for.

Run npx checkly skills communicate for the full protocol details, or npx checkly skills configure for what deploy confirms.

API Pass-Through (fallback for any endpoint)

When no dedicated CLI command exists for an endpoint, use npx checkly api to make authenticated requests directly. The CLI handles auth headers and base URL automatically.

npx checkly api /v1/checks
npx checkly api /v1/dashboards -X GET --jq '.[].name'
npx checkly api /v1/checks -X POST -F name=MyCheck -F activated:=true
npx checkly api /v1/checks -X GET -F limit=5

Key flags: -X (method), -F (field — key=value for strings, key:=value for JSON), -H (header), --jq (filter with jq), --input (body from file/stdin), -i / --include (response status + headers on stdout), --verbose (request/response headers on stderr).

Nested payloads

Use := to send structured JSON in a single field:

npx checkly api /v1/checks/<id> -X PATCH \
  -F retryStrategy:='{"type":"LINEAR","maxRetries":2,"baseBackoffSeconds":10}'

For large or deeply nested bodies, pipe a JSON file via --input:

npx checkly api /v1/checks -X POST --input ./new-check.json

Pagination

checkly api does not auto-walk pages. Drive pagination yourself, the same way every other checkly list command exposes it.

When using -F on a read endpoint, always pass `-X GET` explicitly — any -F flag implies POST unless the method is set, so omitting -X GET will try to create a resource with your pagination params as the body.

Detecting which pagination style an endpoint uses. Make a first request with -i (response headers on stdout) and inspect what came back:

• Page-based → response has a content-range header (e.g. 0-1/23 means items 0–1 of 23 total) and usually a link header with rel="next" / rel="last". The body is a bare array. Walk by incrementing -F page=N until you've covered the total in content-range, or until the rel="next" link disappears.
• Cursor-based → response body is an envelope like { entries: [...], nextId: "...", length: N }. Pass -F nextId=<value> (or -F cursor=<value>, depending on the endpoint) on the next call. When nextId is missing or null, you've reached the end.

# Step 1: make the first call with -i and inspect the response shape
npx checkly api /v1/checks -X GET -F limit=100 -i
 
# If you saw a content-range header → page-based, walk with -F page=N
npx checkly api /v1/checks -X GET -F limit=100 -F page=2 -i
 
# If the body had a nextId field → cursor-based, walk with -F nextId=<value>
npx checkly api /v1/status-pages -X GET -F limit=50 -F nextId=<nextIdFromPrevResponse>

Error responses

On non-2xx, the response body is still written to stdout (read it for the API's error message) and the CLI exits with code 1. A 401 prints an auth hint, a 403 prints a permission hint, and a 404 prints the docs URL — all on stderr.

Endpoint discovery

See the Checkly API reference for the human-readable endpoint catalogue, or fetch the OpenAPI spec for a machine-readable definition you can grep for paths, parameters, and response shapes.

<!-- SKILL_COMMANDS -->