Comprehensive Checkly CLI command reference and Monitoring as Code workflows. Use when user mentions Checkly CLI, monitoring as code, synthetic monitoring, API checks, browser checks, Playwright testing, check deployment, or npx checkly commands. Routes to specialized sub-skills for auth, config, checks, testing, deployment, imports, constructs, and advanced patterns. Triggers on checkly, monitoring as code, synthetic monitoring, checkly cli, npx checkly.
Comprehensive Checkly CLI command reference and Monitoring as Code workflows. Use when user mentions Checkly CLI, monitoring as code, synthetic monitoring, API checks, browser checks, Playwright testing, check deployment, or npx checkly commands. Routes to specialized sub-skills for auth, config, checks, testing, deployment, imports, constructs, and advanced patterns. Triggers on checkly, monitoring as code, synthetic monitoring, checkly cli, npx checkly.
requirements
{"binaries":["checkly","npx"],"binaries_optional":["playwright"],"env_vars":["CHECKLY_API_KEY","CHECKLY_ACCOUNT_ID"],"credential":{"type":"api_key","env_var":"CHECKLY_API_KEY","companion_env_var":"CHECKLY_ACCOUNT_ID","docs_url":"https://www.checklyhq.com/docs/cli/authentication/","storage_path":"~/.config/@checkly/cli/config.json"},"notes":"Requires Checkly account and API key (signup at checklyhq.com/signup or via 'npx checkly login').\nCredentials can be set via environment variables (CHECKLY_API_KEY, CHECKLY_ACCOUNT_ID) or stored in ~/.config/@checkly/cli/config.json via 'npx checkly login'.\nConfig stored in checkly.config.ts and auth credentials in system config.\nBrowser checks require @playwright/test dependency.\n"}
Checkly CLI Skills
Comprehensive Checkly CLI command reference and Monitoring as Code (MaC) workflows.
Quick start
# Create new Checkly project
npm create checkly@latest
# Test checks locally
npx checkly test# Deploy to Checkly cloud
npx checkly deploy
What is Monitoring as Code?
The Checkly CLI provides a TypeScript/JavaScript-native workflow for coding, testing, and deploying synthetic monitoring at scale. Define your monitoring checks as code, test them locally, version control them with Git, and deploy through CI/CD pipelines.
Key benefits:
Codeable - Define checks in TypeScript/JavaScript
Testable - Run checks locally before deployment
Reviewable - Code review your monitoring in PRs
Native Playwright - Use standard @playwright/test specs
CI/CD Native - Integrate with your deployment pipeline
Skill organization
This skill routes to specialized sub-skills by Checkly domain:
Getting Started:
checkly-auth - Authentication setup and login
checkly-config - Configuration files (checkly.config.ts) and project structure
Core Workflows:
checkly-test - Local testing workflow with npx checkly test
checkly-deploy - Deployment to Checkly cloud
checkly-import - Import existing checks from Checkly to code
Check Types:
checkly-checks - API checks, browser checks, multi-step checks
What are you monitoring?
├─ REST API / HTTP endpoint
│ ├─ Simple availability → API Check (request + status assertion)
│ ├─ Complex validation → API Check (request + multiple assertions + scripts)
│ └─ Just uptime/ping → URL Monitor (simpler, faster)
│
├─ Web application / User flow
│ ├─ Single page → Browser Check (one .spec.ts file)
│ ├─ Multiple steps → Browser Check or Multi-Step Check
│ └─ Full test suite → Playwright Check Suite (playwright.config.ts)
│
└─ Service health / Infrastructure
├─ Periodic heartbeat → Heartbeat Monitor
├─ TCP port → TCP Monitor
├─ DNS record → DNS Monitor
└─ Simple HTTP → URL Monitor
Quick reference:
API Check: HTTP requests with assertions (status, headers, body, response time)
Browser Check: Single Playwright spec file for web testing
Multi-Step Check: Complex browser workflows (legacy, use Browser Check instead)
Playwright Check Suite: Multiple Playwright tests with projects/parallelization
Monitors: Simple health checks without code execution
"Test locally or deploy?"
What stage are you at?
├─ Developing new check
│ ├─ Browser check → npx playwright test (fastest iteration)
│ └─ API check → npx checkly test (includes assertions)
│
├─ Ready to validate
│ └─ npx checkly test (runs in Checkly runtime, catches issues)
│
└─ Ready for production
└─ npx checkly deploy (schedule checks to run continuously)
Testing hierarchy:
npx playwright test - Fastest, local Playwright execution (browser checks only)
npx checkly test - Validates in Checkly runtime, catches compatibility issues
npx checkly deploy - Deploys for continuous scheduled monitoring
"File-based or construct-based checks?"
How do you want to define checks?
├─ Auto-discovery (convention over configuration)
│ ├─ Browser checks → *.spec.ts files matching testMatch pattern
│ ├─ Multi-step → *.check.ts files with MultiStepCheck construct
│ └─ API checks → *.check.ts files with ApiCheck construct
│
└─ Explicit definition
├─ Programmatic → Construct instances in .check.ts files
└─ Full control → Playwright Check Suite with playwright.config.ts
Patterns:
Auto-discovery: Configure checks.browserChecks.testMatch in checkly.config.ts
Explicit constructs: Import from checkly/constructs and instantiate
Playwright projects: Define multiple test suites with different configs
"Where should configuration go?"
What are you configuring?
├─ Project-level (all checks)
│ └─ checkly.config.ts → defaults, locations, frequency, runtime
│
├─ Group-level (related checks)
│ └─ CheckGroup construct → shared settings for subset of checks
│
└─ Check-level (individual)
└─ Check constructor → override defaults for specific check
