Agents run on code. So does your monitoring

Every Checkly check, alert, and status page is a TypeScript construct in your repo. That makes your entire reliability setup something an AI agent can write, test on real global infrastructure, and deploy to production. You review the pull request.

Start for freeView docs

Trusted by teams that review everything before it ships

Vercel
Carhartt
CrowdStrike
Airbus
Fanatics
Mistral
ServiceNow
GoFundMe
Hopper
1Password
Fastly
Total Wine

From commit to production monitor in three commands

The check you write is the check you test, and the check you test is the monitor that runs in production. One artifact, one pipeline, and it works exactly the same whether the author is an engineer or an agent.

1

Write

Checks are TypeScript constructs that live next to the code they cover. Your editor autocompletes them, your linter checks them, your teammates review them.

checks/api.check.ts
import { ApiCheck, AssertionBuilder }
from 'checkly/constructs'
 
new ApiCheck('payments-api', {
name: 'Payments API',
frequency: 1, // every minute
locations: ['us-east-1', 'eu-west-1'],
request: {
method: 'GET',
url: 'https://api.acme.com/pay',
assertions: [
AssertionBuilder.statusCode()
.equals(200),
],
},
})
2

Test

One command runs every check on Checkly’s global infrastructure, from your terminal or your CI pipeline. Failing checks fail the build, before anything reaches production.

terminal — local or CI
$ npx checkly test --record
 
Running 6 checks in eu-west-1.
 
✓ Payments API (438ms)
✓ Guest checkout completes (4.2s)
✓ SSO login flow (2.1s)
…
 
6 passed, 6 total
Session: chkly.link/l/8f2a91
3

Deploy

The code that passed in CI becomes your production monitoring. No copy-pasting into a dashboard, no drift between what you tested and what runs.

terminal — on merge to main
$ npx checkly deploy
 
Parsing project ✓
Validating resources ✓
 
Deployed "acme-web" to "Acme"
 
✓ 6 checks live
✓ 2 alert channels wired
✓ 1 status page published
 
Monitoring from 4 locations, 24/7.

npx checkly init scaffolds the project; test and deploy take it from there.

Every monitoring change gets a code review

Nobody quietly edits a check in a dashboard on a Friday afternoon. Changes to your monitoring are commits: reviewed before they merge, tested before they deploy, and one git revert away from being undone.

  • Full history of who changed what, and why, in git blame
  • CI runs every check before the merge, so broken monitors never ship
  • Rollbacks are git reverts, not dashboard archaeology
  • Identical monitoring across staging and production, from one source

Scale with a for loop

Constructs are plain TypeScript. Map over your API routes, read an OpenAPI spec, or share defaults through a check group. Hundreds of monitors from one file, updated in one commit.

Your Playwright tests are already monitors

Point PlaywrightCheck at your existing Playwright config and promote tagged specs to scheduled production monitors. No rewrite, no second test suite to maintain.

CI is the only deploy path you need

Run checkly test on every pull request and checkly deploy on merge. GitHub Actions, GitLab CI, Jenkins: if it runs your pipeline, it runs your monitoring.

If you can click it, you can code it

Your entire reliability setup is constructs: checks and uptime monitors, but also the alert channels, status pages, and maintenance windows around them. One repo describes all of it.

ApiCheck

HTTP calls with assertions on status, latency, headers, and body.

View docs

BrowserCheck

Playwright scripts that click through real user flows.

View docs

PlaywrightCheck

Your existing Playwright project, run on a schedule.

View docs

MultiStepCheck

Chained API calls with shared state, in one check.

View docs

UrlMonitor

Lightweight uptime pings against any URL.

View docs

TcpMonitor

Port-level reachability and connect latency.

View docs

DnsMonitor

Resolution checks with record-level assertions.

View docs

HeartbeatMonitor

Cron jobs and pipelines that must phone home.

View docs

CheckGroupV2

Shared locations, frequency, and alerting for a set of checks.

View docs

SlackAlertChannel

Where alerts land. One of 18+ channel constructs.

View docs

StatusPage

A public status page, deployed from the same repo.

View docs

MaintenanceWindow

Planned downtime without the alert noise.

View docs

Plus dashboards, private locations, ICMP monitors, retry strategies, and escalation policies. The full construct reference covers everything.

Readable by your team. Writable by your agents

Monitoring that lives in code is monitoring your AI agents can own. An agent that ships a feature can write the check, run it, and open the PR, and it clears the same review gate as everyone else.

  • Plain TypeScript constructs any agent can read, write, and refactor
  • An MCP server for creating, running, and deploying checks
  • Agent skills for Claude Code, Cursor, and Copilot
  • One review gate for humans and agents alike: the pull request

Explore Checkly for AI agents

Bring your own toolchain

The CLI is the fast path, but it is not the only one. Every Checkly resource is also available through Terraform, Pulumi, and a fully documented REST API.

Checkly CLI

Native

The native workflow. TypeScript constructs, local test runs, CI deploys.

Learn more

Terraform

Manage checks alongside the rest of your infrastructure.

Learn more

Pulumi

Define monitors inside the Pulumi stacks you already run.

Learn more

REST API

Full CRUD on every resource, for anything you build yourself.

Learn more

Frequently asked questions

Everything you need to know about running monitoring as code with Checkly.

Monitoring as code means your monitoring setup is defined in version-controlled source files instead of a dashboard. With Checkly, API checks, browser checks, uptime monitors, alert channels, and status pages are TypeScript constructs that live in your repo. You test them from your terminal or CI with npx checkly test and deploy them with npx checkly deploy, so every change ships through a pull request like any other code.

npx checkly test runs every check in your project on Checkly’s global infrastructure straight from your terminal, without deploying anything. Add --record to get a shareable test session with full traces, videos, and logs. Run the same command in CI on every pull request, and nothing reaches production monitoring until it has passed the exact run it will perform in production.

Yes. The PlaywrightCheck construct points at your playwright.config.ts and promotes selected projects or tagged specs to scheduled monitors. Checkly runs standard @playwright/test, so your specs stay in your repo, unchanged, with no vendor-specific rewrite and no second suite to maintain.

Everything in Checkly is a construct: API, browser, multistep, and Playwright checks; URL, TCP, DNS, ICMP, and heartbeat monitors; check groups, alert channels, retry strategies, and escalation policies; status pages, dashboards, maintenance windows, and private locations. If you can click it in the UI, you can commit it to git.

No. npx checkly import pulls your existing checks, groups, and alert channels into constructs, so you can adopt the code workflow incrementally. Code and UI have full parity, and teams that prefer Terraform or Pulumi can use those providers instead of the CLI.

Yes, by design. Constructs are plain TypeScript that agents can read, write, and refactor, and the Checkly MCP server plus agent skills let Claude Code, Cursor, and other agents create checks, run them, and deploy them. Because everything ships through git, agent-written monitoring goes through the same code review as everything else.

Your first monitor is one commit away

Scaffold a project, write a check, and deploy it before your coffee gets cold. Everything after that is a pull request.

$npx checkly init
Start for freeBook a demo