Checkly CLI Skills
Comprehensive Checkly CLI command reference and Monitoring as Code (MaC) workflows.
Quick start
CODEBLOCK0
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 - INLINECODE1 - Configuration files (checkly.config.ts) and project structure
Core Workflows:
- -
checkly-test - Local testing workflow with npx checkly test - INLINECODE3 - Deployment to Checkly cloud
- INLINECODE4 - Import existing checks from Checkly to code
Check Types:
- -
checkly-checks - API checks, browser checks, multi-step checks - INLINECODE6 - Heartbeat, TCP, DNS, URL monitors
- INLINECODE7 - Check groups for organization and shared config
Advanced:
- -
checkly-constructs - Constructs system and resource management - INLINECODE9 - Playwright test suites and configuration
- INLINECODE10 - Retry strategies, reporters, environment variables, bundling
When to use Checkly CLI vs Web UI
Use Checkly CLI when:
- - Defining monitoring as part of your codebase
- Automating check creation/updates in CI/CD
- Testing checks locally during development
- Version controlling monitoring configuration
- Managing multiple checks efficiently
- Integrating monitoring with application deployments
Use Web UI when:
- - Exploring Checkly for the first time
- Viewing dashboards and historical results
- Analyzing check failures and incidents
- Managing account-level settings
- Configuring alert channels (email, Slack, PagerDuty)
- Setting up private locations
Common workflows
New project setup
CODEBLOCK1
Daily development
CODEBLOCK2
Browser check with Playwright
CODEBLOCK3
Import existing checks
CODEBLOCK4
Decision Trees
"What type of check should I create?"
CODEBLOCK5
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?"
CODEBLOCK6
Testing hierarchy:
- 1.
npx playwright test - Fastest, local Playwright execution (browser checks only) - INLINECODE12 - Validates in Checkly runtime, catches compatibility issues
- INLINECODE13 - Deploys for continuous scheduled monitoring
"File-based or construct-based checks?"
CODEBLOCK7
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?"
CODEBLOCK8
Configuration hierarchy (specific overrides general):
- 1. Check-level properties (highest priority)
- CheckGroup properties
- checkly.config.ts defaults
- Checkly account defaults (lowest priority)
Project structure
Typical Checkly CLI project:
CODEBLOCK9
Installation methods
New project (recommended)
CODEBLOCK10
Creates scaffolded project with:
- -
checkly.config.ts with sensible defaults - Example checks in
__checks__/ directory - INLINECODE18 with checkly dependency
- INLINECODE19 configured
Existing project
CODEBLOCK11
Global installation (not recommended)
CODEBLOCK12
Note: Use npx checkly instead for project-specific CLI version.
Related Skills
Getting started:
- - See
checkly-auth for authentication setup - See
checkly-config for project configuration - See
checkly-test for local testing workflow
Creating checks:
- - See
checkly-checks for API and browser checks - See
checkly-monitors for simpler health checks - See
checkly-playwright for full test suite setup
Advanced workflows:
- - See
checkly-deploy for deployment strategies - See
checkly-constructs for understanding the object model - See
checkly-advanced for retry strategies and reporters
Import existing:
- - See
checkly-import to migrate from web UI to code
Checkly CLI 技能
全面的 Checkly CLI 命令参考和监控即代码 (MaC) 工作流程。
快速开始
bash
创建新的 Checkly 项目
npm create checkly@latest
本地测试检查
npx checkly test
部署到 Checkly 云
npx checkly deploy
什么是监控即代码?
Checkly CLI 提供 TypeScript/JavaScript 原生工作流程,用于大规模编码、测试和部署合成监控。将监控检查定义为代码,在本地测试,通过 Git 进行版本控制,并通过 CI/CD 管道部署。
主要优势:
- - 可编码 - 使用 TypeScript/JavaScript 定义检查
- 可测试 - 在部署前本地运行检查
- 可审查 - 在 PR 中对监控进行代码审查
- 原生 Playwright - 使用标准 @playwright/test 规范
- CI/CD 原生 - 与部署管道集成
技能组织
本技能按 Checkly 领域路由到专业子技能:
入门指南:
- - checkly-auth - 认证设置和登录
- checkly-config - 配置文件 (checkly.config.ts) 和项目结构
核心工作流程:
- - checkly-test - 使用 npx checkly test 进行本地测试工作流程
- checkly-deploy - 部署到 Checkly 云
- checkly-import - 从 Checkly 导入现有检查到代码
检查类型:
- - checkly-checks - API 检查、浏览器检查、多步骤检查
- checkly-monitors - 心跳、TCP、DNS、URL 监控器
- checkly-groups - 用于组织和共享配置的检查组
高级:
- - checkly-constructs - 构造系统和资源管理
- checkly-playwright - Playwright 测试套件和配置
- checkly-advanced - 重试策略、报告器、环境变量、打包
何时使用 Checkly CLI 与 Web UI
使用 Checkly CLI 时:
- - 将监控定义为代码库的一部分
- 在 CI/CD 中自动化检查创建/更新
- 在开发期间本地测试检查
- 对监控配置进行版本控制
- 高效管理多个检查
- 将监控与应用程序部署集成
使用 Web UI 时:
- - 首次探索 Checkly
- 查看仪表板和历史结果
- 分析检查失败和事件
- 管理账户级设置
- 配置警报渠道(电子邮件、Slack、PagerDuty)
- 设置私有位置
常见工作流程
新项目设置
bash
初始化项目
npm create checkly@latest
cd my-checkly-project
认证
npx checkly login
本地测试
npx checkly test
部署到云
npx checkly deploy
日常开发
bash
创建新的 API 检查
cat >
checks/api-status.check.ts <
import { ApiCheck, AssertionBuilder } from checkly/constructs
new ApiCheck(api-status-check, {
name: API 状态检查,
request: {
url: https://api.example.com/status,
method: GET,
assertions: [
AssertionBuilder.statusCode().equals(200),
AssertionBuilder.responseTime().lessThan(500),
],
},
})
EOF
本地测试
npx checkly test
准备就绪后部署
npx checkly deploy
使用 Playwright 的浏览器检查
bash
创建浏览器检查
cat > checks/homepage.spec.ts <
import { test, expect } from @playwright/test
test(首页加载, async ({ page }) => {
const response = await page.goto(https://example.com)
expect(response?.status()).toBeLessThan(400)
await expect(page).toHaveTitle(/Example/)
await page.screenshot({ path: homepage.jpg })
})
EOF
使用 Playwright 本地测试(更快)
npx playwright test checks/homepage.spec.ts
通过 Checkly 运行时测试
npx checkly test checks/homepage.spec.ts
部署
npx checkly deploy
导入现有检查
bash
从 Checkly 账户导入所有检查
npx checkly import plan
审查生成的代码
git diff
提交导入的检查
git add .
git commit -m 导入现有监控检查
决策树
我应该创建什么类型的检查?
你在监控什么?
├─ REST API / HTTP 端点
│ ├─ 简单可用性 → API 检查(请求 + 状态断言)
│ ├─ 复杂验证 → API 检查(请求 + 多个断言 + 脚本)
│ └─ 仅正常运行时间/ ping → URL 监控器(更简单、更快)
│
├─ Web 应用程序 / 用户流程
│ ├─ 单页面 → 浏览器检查(一个 .spec.ts 文件)
│ ├─ 多步骤 → 浏览器检查或多步骤检查
│ └─ 完整测试套件 → Playwright 检查套件 (playwright.config.ts)
│
└─ 服务健康 / 基础设施
├─ 定期心跳 → 心跳监控器
├─ TCP 端口 → TCP 监控器
├─ DNS 记录 → DNS 监控器
└─ 简单 HTTP → URL 监控器
快速参考:
- - API 检查:带有断言的 HTTP 请求(状态、标头、正文、响应时间)
- 浏览器检查:用于 Web 测试的单个 Playwright 规范文件
- 多步骤检查:复杂的浏览器工作流程(旧版,改用浏览器检查)
- Playwright 检查套件:带有项目/并行化的多个 Playwright 测试
- 监控器:无需代码执行的简单健康检查
本地测试还是部署?
你处于哪个阶段?
├─ 开发新检查
│ ├─ 浏览器检查 → npx playwright test(最快迭代)
│ └─ API 检查 → npx checkly test(包含断言)
│
├─ 准备验证
│ └─ npx checkly test(在 Checkly 运行时运行,捕获问题)
│
└─ 准备生产
└─ npx checkly deploy(安排检查持续运行)
测试层次:
- 1. npx playwright test - 最快,本地 Playwright 执行(仅浏览器检查)
- npx checkly test - 在 Checkly 运行时验证,捕获兼容性问题
- npx checkly deploy - 部署用于持续计划监控
基于文件还是基于构造的检查?
你想如何定义检查?
├─ 自动发现(约定优于配置)
│ ├─ 浏览器检查 → 匹配 testMatch 模式的 *.spec.ts 文件
│ ├─ 多步骤 → 带有 MultiStepCheck 构造的 *.check.ts 文件
│ └─ API 检查 → 带有 ApiCheck 构造的 *.check.ts 文件
│
└─ 显式定义
├─ 编程式 → .check.ts 文件中的构造实例
└─ 完全控制 → 带有 playwright.config.ts 的 Playwright 检查套件
模式:
- - 自动发现:在 checkly.config.ts 中配置 checks.browserChecks.testMatch
- 显式构造:从 checkly/constructs 导入并实例化
- Playwright 项目:使用不同配置定义多个测试套件
配置应该放在哪里?
你在配置什么?
├─ 项目级(所有检查)
│ └─ checkly.config.ts → 默认值、位置、频率、运行时
│
├─ 组级(相关检查)
│ └─ CheckGroup 构造 → 检查子集的共享设置
│
└─ 检查级(单个)
└─ Check 构造函数 → 覆盖特定检查的默认值
配置层次(特定覆盖通用):
- 1. 检查级属性(最高优先级)
- CheckGroup 属性
- checkly.config.ts 默认值
- Checkly 账户默认值(最低优先级)
项目结构
典型的 Checkly CLI 项目:
my-monitoring-project/
├── checkly.config.ts # 项目配置
├── checks/ # 检查定义
│ ├── api.check.ts # API 检查构造
│ ├── homepage.spec.ts # 浏览器检查(自动发现)
│ ├── login.spec.ts # 另一个浏览器检查
│ └── utils/
│ ├── alert-channels.ts # 共享警报渠道定义
│ └── helpers.ts # 共享辅助