Monitoring as Code

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.

“The ease of integration in our pipeline was remarkable. We have everything defined in a CI/CD pipeline using GitHub Actions using the CLI. Everything scaffolds out based on a configuration, so we just update a configuration file which specifies the environments, what services are there, what the URLs are, and from that, we just generate all the groups and their checks.”

Tobias Deekens

Principal Frontend Engineer · commercetools

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. The browser and API constructs are how teams run synthetic monitoring as code, with the same review and deploy path as the application they watch.

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

Key facts

Monitoring as code, in facts

How monitors are defined, tested, and deployed when they live in your repository, and what the approach does not solve on its own.

What it is

Monitors defined in source control, not a console

Checks, alert channels, groups, and status pages are declared in files, reviewed in pull requests, and applied by a deploy command.

Checkly monitoring as code docs (opens in a new tab)

Languages

TypeScript and JavaScript

Constructs are typed, so an invalid frequency or a missing assertion fails in your editor rather than at runtime.

Checkly CLI docs (opens in a new tab)

Infrastructure as code

Terraform and Pulumi providers

Teams that already manage infrastructure in Terraform or Pulumi can declare monitors in the same stack instead of adopting a second workflow.

Checkly monitoring as code docs (opens in a new tab)

Local feedback

Run checks before they are deployed

The CLI runs a check against any environment from your machine or from CI, so a monitor is tested the way application code is.

Checkly CLI docs (opens in a new tab)

Agents

No agent to install on your hosts

Checks run from Checkly infrastructure. An agent is only needed for private locations that reach services inside your network.

Checkly locations docs (opens in a new tab)

What it does not remove

The need to review checks like code

Monitoring as code moves monitors into the pull-request workflow. It does not by itself keep coverage current if nobody reviews it.

Checkly monitoring as code docs (opens in a new tab)

Facts checked . Vendor pricing and feature pages change without notice, so verify anything decision-critical against the linked source.

Fit check

Is monitoring as code right for your team?

Checkly is a strong fit when

  • Monitoring coverage keeps drifting behind the product because checks live somewhere the shipping team does not look.
  • You want a check tested locally and in CI before it ever pages anyone.
  • Your infrastructure is already declared in Terraform or Pulumi and monitoring is the exception.

Checkly may not be the best fit when

  • Your monitors are configured and owned by a team that does not work in Git, and moving them there is not the goal.
  • You want a monitoring setup finished in an afternoon with no repository, pipeline, or review step.
  • You need infrastructure metrics or log pipelines as code. That is a different tool from monitoring as code.

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