Synthetic monitoring for developers

Monitoring that works like your code does

Write checks in TypeScript next to the services they cover, run them on every pull request, and deploy them with your app. Playwright-native, versioned in git, and plain enough that Claude Code or Cursor can write and maintain your monitors alongside the features they cover.

Start for freeRead docs
TypeScript, not YAMLPlaywright-nativeRuns in your CIAlerts + status pages as code
__checks__/checkout.check.ts
1// __checks__/checkout.check.ts
2import * as path from 'path'
3import { BrowserCheck, Frequency } from 'checkly/constructs'
4
5// A monitor is a file in your repo, like everything else you ship
6new BrowserCheck('checkout-flow', {
7 name: 'Checkout flow',
8 frequency: Frequency.EVERY_5M,
9 locations: ['us-east-1', 'eu-west-1'],
10 code: {
11 entrypoint: path.join(__dirname, 'checkout.spec.ts'),
12 },
13})

Trusted by engineers who own what they ship

Vercel
Carhartt
CrowdStrike
Airbus
Fanatics
Mistral
ServiceNow
GoFundMe
Hopper
1Password
Fastly
Total Wine
“Checkly is a fabulous developer tool. The flexible features and developer-friendly API made the integration super easy, and their support is friendly and knowledgeable.”
Connor Hicks·Lead Developer · 1Password

Why developers end up hating their monitoring tools

The category grew up next to IT operations, not next to your repo. It shows.

Monitoring feels like an IT tool

Clunky dashboards, checks configured by hand, zero version control. It watches your code, but it works nothing like it.

A second language for a first-class job

Monitoring products want their own DSL, their own editor, their own snowflake config. Your app is code. Your monitoring should not be a dialect of YAML.

Green in CI, broken in prod

Tests pass on every merge, then a third-party API, an expired cert, or a bad deploy breaks the flow at 9 p.m. Nothing was watching.

Checkly is built like a dev tool instead: checks are TypeScript in your repo, they run in CI before they run in production, and Playwright is the native language for browser flows. So is everything that happens after one fails. The channel it alerts, the incident it opens on your status page, and the trace you debug from are all constructs in the same project, shipped in the same pull request.

“We’ve been using Checkly for months and it’s been phenomenal. Super easy to set up, works flawlessly and intuitively. The team is super receptive and quick to help.”

Jake Cooper

Founder / Engineer · Railway

Reuse the tests you already wrote

A browser check is a standard Playwright spec, so the specs in your repo become monitors as they are. An API check is a typed construct with assertions. No vendor SDK to learn, no script editor to click through, nothing that stops working when you refactor.

  • Standard @playwright/test for browser flows, no vendor rewrite
  • API checks with typed request builders and assertions
  • The same file runs locally, in CI, and as a production monitor
  • Plain TypeScript constructs your AI agents can read and write
__checks__/checkout.spec.ts
1// __checks__/checkout.spec.ts
2import { test, expect } from '@playwright/test'
3
4test('guest checkout completes', async ({ page }) => {
5 await page.goto('https://acme.com/store')
6
7 await page.getByRole('button', { name: 'Add to cart' }).click()
8 await page.getByRole('link', { name: 'Checkout' }).click()
9
10 await expect(page.getByText('Order confirmed')).toBeVisible()
11})

Monitoring with testing built in

npx checkly test runs your checks from CI on every pull request, on the same global infrastructure they'll run on in production. A failing check fails the build, so the regression never ships.

  • Run the full check suite on every pull request
  • A failing check fails the build, before anything reaches users
  • --record captures a shareable session with trace, video, and logs
  • The exact run it will perform in production, not an approximation
CI · pull request #482
$ npx checkly test --record
 
Running 3 checks in eu-west-1.
 
✓ Payments API (401ms)
✓ SSO login (2.9s)
✕ Checkout flow (12.4s)
Error: Timed out 5000ms waiting for
expect(locator).toBeVisible()
 
build failed · regression never merged

Deploy monitors right alongside your application and services

Monitors ship from the same pipeline as your app. Merge to main, and the checks that guard the new feature go live with it. No ticket to another team, no dashboard to remember.

  • npx checkly deploy from GitHub Actions, GitLab CI, or any runner
  • Monitoring changes travel in the same PR as the feature
  • Preview what changed before it applies, roll back with git revert
  • Works with monorepos: checks live next to the service they cover
.github/workflows/monitors.yml
1# .github/workflows/monitors.yml
2name: Deploy monitors
3on:
4 push:
5 branches: [main]
6jobs:
7 deploy:
8 runs-on: ubuntu-latest
9 steps:
10 - uses: actions/checkout@v4
11 - run: npm ci
12 - run: npx checkly deploy --force
13 env:
14 CHECKLY_API_KEY: ${{ secrets.CHECKLY_API_KEY }}
15 CHECKLY_ACCOUNT_ID: ${{ secrets.CHECKLY_ACCOUNT_ID }}

The alert and the status page are files too

Most tools let you write the check in code and then make you click the rest: the channel it alerts, the incident it opens, the page your customers refresh. In Checkly those are constructs in the same project. Wire a check to a status page service once, and the incident opens when it fails and closes when it recovers.

  • Alert channels are typed constructs: Slack, PagerDuty, SMS, webhooks
  • StatusPage and StatusPageService live in the same project as the checks
  • triggerIncident opens and resolves the incident, and notifies subscribers
  • Custom domain, theme, and cards reviewed in the pull request that changes them

More on alerting →More on status pages →

__checks__/checkout.check.ts
1// __checks__/checkout.check.ts
2import * as path from 'path'
3import {
4 BrowserCheck, SlackAlertChannel,
5 StatusPage, StatusPageService,
6} from 'checkly/constructs'
7
8const slack = new SlackAlertChannel('slack-eng', {
9 url: new URL(process.env.SLACK_WEBHOOK_URL!),
10 channel: '#eng-alerts',
11})
12
13const storefront = new StatusPageService('storefront', {
14 name: 'Storefront',
15})
16
17new BrowserCheck('checkout-flow', {
18 name: 'Checkout flow',
19 code: { entrypoint: path.join(__dirname, 'checkout.spec.ts') },
20
21 // Where your team hears about it
22 alertChannels: [slack],
23
24 // And where your users do, without anyone posting an update
25 triggerIncident: {
26 service: storefront,
27 severity: 'MAJOR',
28 name: 'Checkout degraded',
29 description: 'The checkout flow check is failing.',
30 notifySubscribers: true,
31 },
32})
33
34new StatusPage('acme-status', {
35 name: 'Acme Status',
36 url: 'acme-status',
37 customDomain: 'status.acme.com',
38 cards: [{ name: 'Storefront', services: [storefront] }],
39})

Made for the tools you already use

Playwright for the flows, your CI for the pipeline, Slack for the alerts, and an API for everything else.

Playwright

Browser checks are standard @playwright/test specs, not scripts in a proprietary editor. What you know already applies.

Learn more

GitHub Actions

Run every check on pull requests with npx checkly test, then deploy them on merge to main.

Learn more

GitLab CI

The same workflow on GitLab: test, record a session, and deploy monitors from your pipeline.

Learn more

Vercel

Run checks against your preview and production deployments as part of the deploy.

Learn more
Slack

Slack

Rich alerts in any channel, with failure context and a link to the result.

Learn more

REST API + webhooks

Full CRUD on every resource for anything you build yourself, plus raw webhooks with full payload control.

Learn more

Status pages

A StatusPage construct in the same project as your checks. Incidents open and close themselves when a check fails and recovers.

Learn more

Traces

OpenTelemetry spans link a failed check to the backend request behind it. Export them to Tempo, Honeycomb, or Datadog.

Learn more

Rocky AI

Reads the error, the screenshot, and the trace, then tells you what broke in a sentence you can paste into the PR that fixes it.

Learn more

Debug from the failure, not from scratch

You open the Slack alert on your phone. Before you have found a laptop you already know it is not your code, because the run kept its evidence and Rocky AI read the trace attached to it. That is the difference between an incident and a git bisect at 9 p.m.

  • Screenshot, video replay, console and network logs on the run itself
  • OpenTelemetry spans link the failed check to the request that broke
  • Rocky AI names the cause, dependency failures included
  • Every alert links straight to the run, so the reproduction is one tap away

See how Rocky AI reads a failure →

Developers, on Checkly

“We’ve saved a lot of time by using Playwright with Checkly.”

Keegan Donley

Senior Front-End Engineer · Kizen

“Checkly is incredible: it combines Pingdom, Ghost Inspector, and Assertible in the same app, and the insights are much more detailed.”

Leo Lamprecht

SVP Product · Vercel

“Checkly was incredibly easy to integrate. Even our initial traces setup was quick, and the documentation was better than OTel’s own.”

Brian Stack

Infrastructure Engineer · Render

“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

“Checkly Traces helped us resolve issues faster by showing exactly how long database calls are taking. This insight was crucial in pinpointing N+1 issues and optimizing caching. Having a vendor like Checkly levels up your team to the point where it starts to feel like an unfair advantage.”

James Hall

AWS Hero & Founder · Parallax

“The Checkly CLI has enhanced our engineering team’s ability to quickly build, validate, and deploy an entire suite of checks from their local development environment.”

Tavares Chambless

Manager, Quality Assurance · Loyal Health

Frequently asked questions

The developer workflow: from npm install to a monitor in production.

Minutes, from the terminal. npm create checkly scaffolds a project with example checks, npx checkly test runs them on Checkly’s global infrastructure without deploying anything, and npx checkly deploy puts them into production monitoring. No dashboard setup required.

No. Checks are TypeScript constructs and browser checks are standard @playwright/test specs. If you can write a unit test, you can write a monitor. Everything also has full parity in the web app for anyone who prefers the UI.

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.

npx checkly test runs your checks from CI on every pull request and fails the build if a check fails. Add --record for a shareable test session with traces, videos, and logs. On merge, npx checkly deploy ships the updated monitors. There are guides for GitHub Actions, GitLab CI, Jenkins, and Vercel, and the CLI runs anywhere Node runs.

The full context: a screenshot, video replay, trace, and an AI root cause analysis of the failed run. Alerts land in Slack, email, or any of 18+ channels with a link straight to the result.

Yes, and this is the part most tools make you click. AlertChannel, StatusPage, and StatusPageService are constructs like any other, so they live in the same project as your checks and ship in the same deploy. Point a check at a status page service with triggerIncident and the incident opens when the check fails, notifies subscribers, and resolves itself when the check recovers.

Two ways. Traces: checks emit OpenTelemetry spans, so a failed run links to the backend request behind it, and you can export those spans to Tempo, Honeycomb, or Datadog. Rocky AI: it reads the error, the screenshot, and the correlated trace, then gives you a plain-language root cause, including when the fault is in a third-party dependency rather than your code.

Yes. Because checks are plain TypeScript files in your repo, agents like Claude Code or Cursor can create, update, and maintain them like any other code, and the CLI is fully scriptable for test and deploy. Your monitoring evolves in the same pull requests as the features it covers.

Your next monitor is a pull request

npm create checkly, write a spec, open the PR. Your first check can be guarding production this afternoon.

Start for freeRead the CLI docs