Synthetic monitoring for QA engineers

Your Playwright tests are already monitors

Point Checkly at your playwright.config.ts and promote tagged specs to production monitors, unchanged. The suite you maintain for CI keeps working after the deploy: on a schedule, from 22+ regions, with alerting attached.

Start for freeView docs
One suite, two jobsVideo, trace, screenshots kept
__checks__/critical-flows.check.ts
1// __checks__/critical-flows.check.ts
2import { PlaywrightCheck, Frequency } from 'checkly/constructs'
3
4// Promote the specs tagged @critical to production monitors
5new PlaywrightCheck('critical-flows', {
6 name: 'Critical user flows',
7 playwrightConfigPath: './playwright.config.ts',
8 pwTags: ['@critical'],
9 frequency: Frequency.EVERY_10M,
10 locations: ['us-east-1', 'eu-west-1'],
11})

Trusted by teams that test what they ship

Vercel
Carhartt
CrowdStrike
Airbus
Fanatics
Mistral
ServiceNow
GoFundMe
Hopper
1Password
Fastly
Total Wine
“We’ve saved a lot of time by using Playwright with Checkly.”

It only took me a few minutes to get a login check working and determine if we could log in and validate that the CDN was up.

Keegan Donley·Senior Front-End Engineer · Kizen

The gap between your test suite and production

You already test the flows that matter. The problem is what happens after the merge.

Coverage ends at the merge

The suite runs on every pull request, then the deploy goes out and nothing runs it again. Production breaks in exactly the flows you have tests for.

The second suite

Adopting a monitoring tool used to mean rewriting your flows in its script editor, then maintaining both copies forever. Every UI change now costs you twice.

Users file the bug report

A checkout regression at 9 p.m. reaches support before it reaches QA, while the status page still says all systems operational. By morning it’s a ticket queue, a refund thread, and a postmortem.

Checkly runs standard @playwright/test in production. The specs stay in your repo, tags decide what gets promoted, and a failure alerts your team with the trace attached.

“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

Just @tag and it's a monitor

The spec below is a normal Playwright test. Add a tag, and the PlaywrightCheck construct promotes it to a scheduled production monitor. Write once; it guards the flow forever.

  • Promote by tag or by Playwright project, straight from your config
  • Specs stay in your repo with your fixtures and helpers
  • A new spec with the right tag is automatically part of the monitor
  • No script editor, no copy in a vendor database to keep in sync
e2e/checkout.spec.ts
1// e2e/checkout.spec.ts — the spec you already have
2import { test, expect } from '@playwright/test'
3
4test('guest checkout completes @critical', async ({ page }) => {
5 await page.goto('/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})

API journeys are specs too

Multi-step API flows use the same @playwright/test you already write: the request fixture for calls, test.step for structure. Create, verify, and clean up against production, every few minutes.

  • test.step gives every stage its own pass/fail in the results
  • Chain requests: create an order, assert on it, cancel it
  • The same assertions library you use everywhere else
  • Runs from 22+ public regions or inside your own network
e2e/order-api.spec.ts
1// e2e/order-api.spec.ts
2import { test, expect } from '@playwright/test'
3
4test('order lifecycle @critical', async ({ request }) => {
5 let orderId: string
6
7 await test.step('create order', async () => {
8 const res = await request.post('https://api.acme.com/orders', {
9 data: { sku: 'A-102', qty: 1 },
10 })
11 expect(res.status()).toBe(201)
12 orderId = (await res.json()).id
13 })
14
15 await test.step('cancel order', async () => {
16 const res = await request.delete(
17 `https://api.acme.com/orders/${orderId}`
18 )
19 expect(res.ok()).toBeTruthy()
20 })
21})

One suite. Local, CI, and production

The same spec runs three ways: locally while you write it, in CI to gate the merge, and in production as a monitor. Maintain it once, and every UI change costs you one fix instead of three. Only the third one needs retries, an escalation policy, and somebody to wake, which is the part CI never had to give you.

  • npx checkly test runs your suite on the same infrastructure as production monitoring
  • --record produces a shareable session: bug report as a link, not a recipe
  • npx checkly deploy promotes the suite; git revert rolls it back
  • Retries and escalation policies keep a flake from paging the team at 3 a.m.
  • Full parity in the web UI for teammates who want to browse results

More on alerting →

one suite, three jobs
# locally, while you write it
$ npx playwright test --grep @critical
 
# in CI, on Checkly's global infrastructure
$ npx checkly test --record
 
# in production, on a schedule, with alerting
$ npx checkly deploy

Your suite becomes the status customers see

Most status pages are wired to a ping, which is why they say all systems operational while checkout is broken. You already have something better: the specs that assert a user can actually complete the flow. Point those at a status page service and the incident opens itself the moment the flow breaks.

  • StatusPage and StatusPageService sit in the same project as the specs
  • triggerIncident opens the incident, notifies subscribers, and closes on recovery
  • Your own domain, public or private, no separate status page vendor
  • The page reflects a completed user journey, not an HTTP 200

More on status pages →

__checks__/critical-flows.check.ts
1// __checks__/critical-flows.check.ts
2import {
3 PlaywrightCheck, Frequency,
4 StatusPage, StatusPageService,
5} from 'checkly/constructs'
6
7// The flows you promoted are the ones customers judge you on
8const checkout = new StatusPageService('checkout', { name: 'Checkout' })
9const signIn = new StatusPageService('sign-in', { name: 'Sign in' })
10
11new PlaywrightCheck('critical-flows', {
12 name: 'Critical user flows',
13 playwrightConfigPath: './playwright.config.ts',
14 pwTags: ['@critical'],
15 frequency: Frequency.EVERY_10M,
16
17 // QA's suite, published. Opens and closes itself.
18 triggerIncident: {
19 service: checkout,
20 severity: 'MAJOR',
21 name: 'Checkout degraded',
22 description: 'The guest checkout flow is failing.',
23 notifySubscribers: true,
24 },
25})
26
27new StatusPage('acme-status', {
28 name: 'Acme Status',
29 url: 'acme-status',
30 customDomain: 'status.acme.com',
31 cards: [{ name: 'Core flows', services: [checkout, signIn] }],
32})

Slots into the pipeline you already run

Playwright for the specs, your CI for the gate, and alerts wherever your team reads them.

Playwright

Checkly runs standard @playwright/test. Your specs, your fixtures, your config, promoted to monitors unchanged.

Learn more

GitHub Actions

Gate merges with npx checkly test on every pull request, deploy the suite on merge.

Learn more

GitLab CI

The same test-and-deploy workflow from your GitLab pipelines.

Learn more
Slack

Slack

A failed flow posts to your team channel with the context and a link to the run.

Learn more

Microsoft Teams

Post alerts to team channels through incoming webhooks.

Learn more

Webhooks + 18 channels

PagerDuty, Opsgenie, email, SMS, phone calls, and raw webhooks with full payload control for everything else.

Learn more

Status pages

The flows you promoted drive a status page on your own domain. Incidents open when a check fails and close when it recovers.

Learn more

Traces

Follow a failing step past the browser into the backend request, so the bug report names the service that returned the error.

Learn more

Rocky AI

Reads the error, the screenshot, and the trace, then names the likely cause. Triage starts with a hypothesis.

Learn more

The bug report writes itself

The hardest part of QA was never finding the bug. It was proving it: the reproduction steps, the environment, the argument that it is real and not a flaky selector. A failed run carries all three, and Rocky AI has already read them. You hand over a link and a hypothesis.

  • Screenshot, video replay, console and network logs on the run itself
  • The trace goes past the browser, so you can name the service that returned the error
  • Pass-rate history separates a regression from a spec that needs a better selector
  • Runs recorded with --record are shareable, so a ticket can be a link

See how Rocky AI reads a failure →

One suite, two jobs, in the wild

“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

“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

“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

“We love Heartbeat Checks! They help us ensure that critical operations run to completion and on time. We had previously evaluated other platforms just for their heartbeat checks, so we are happy to see these within Checkly along with the API and browser checks.”

Johannes Gilger

CEO & Founder · urlscan.io

“A real advantage Checkly gives us is that we’re not waiting for users to report an issue, or waiting on a staff member to file a ticket. Checkly gives us real-time feedback on what is and isn’t working.”

Thomas Reither

Associate Consultant · Solutia

Frequently asked questions

Specs, schedules, artifacts, and how one Playwright suite covers CI and production.

Yes. Checkly executes standard @playwright/test. The PlaywrightCheck construct points at your playwright.config.ts and promotes the projects or tagged specs you choose. Your specs stay in your repo, with your fixtures and your helpers, and there is no vendor-specific rewrite.

The spec is the same; the schedule and the audience change. CI runs gate a merge, once, against a preview build. Monitors run the same spec continuously in production, from multiple regions, with retries to absorb flakes and alert channels attached so a real failure reaches your team. One suite covers both.

Checkly executes @playwright/test, so Cypress specs need porting before they can run as browser checks. Many teams treat that port as the moment testing and monitoring consolidate into one Playwright suite. Until then, API checks and uptime monitors work regardless of your test framework.

The full evidence: a screenshot, video replay, trace, and error logs, plus an AI root cause analysis of what broke. Runs recorded with npx checkly test --record produce shareable sessions, so a bug report can be a link instead of a reproduction recipe.

Yes. Each PlaywrightCheck sets its own schedule (down to every minute for API checks and high-frequency needs), its own set of the 22+ global locations or your private locations, and its own retry strategy. Tag specs to slice one repo into different suites with different policies.

Yes. Every check has full parity in the web UI, dashboards give shareable tag-filtered views, and status pages publish uptime without any login. Alerts in Slack or Teams link straight to the failed run, which anyone on the team can open.

Yes, and that is usually the point of promoting flows in the first place. Status pages run on your own domain, public or private, and the services on them are wired to the checks you already promoted. Point a check at a service with triggerIncident and the incident opens when the check fails, notifies subscribers, and resolves when it recovers, so nobody is copying a Slack thread into a customer update.

Read the trace and let Rocky AI go first. Checks emit OpenTelemetry spans, so a failing step links to the backend request behind it rather than stopping at the browser. Rocky AI reads the error, the screenshot, and that trace together and returns a plain-language cause, including when the fault sits in a third-party dependency. QA hands over a hypothesis rather than a reproduction recipe.

Your suite already does the hard part

The flows are written and the assertions are solid. Point Checkly at your config and put them to work in production.

Start for freeRead the docs