Synthetic monitoring for SREs

The synthetic layer for your observability stack. Managed as code, not clicks

Declare uptime, API, and browser checks in TypeScript or Terraform. Deploy them from CI, run them from 22+ regions or inside your own VPC, and page on-call only after a failure is confirmed. The same check opens the status page incident and hands the rotation a root cause.

Start for freeBook a demo
22+ public regionsPrivate locationsTypeScript · Terraform · Pulumi
__checks__/fleet.check.ts
1import {
2 ApiCheck, CheckGroupV2, AssertionBuilder,
3} from 'checkly/constructs'
4import { services } from './services.config'
5
6const ok = AssertionBuilder.statusCode().equals(200)
7
8const prod = new CheckGroupV2('prod-fleet', {
9 name: 'Production fleet',
10 locations: ['us-east-1', 'eu-west-1'],
11})
12
13// Every service gets a monitor.
14// No clicks, no drift.
15for (const svc of services) {
16 new ApiCheck(`${svc.slug}-health`, {
17 name: `${svc.name} /health`,
18 group: prod,
19 frequency: 1,
20 request: {
21 method: 'GET',
22 url: `${svc.baseUrl}/health`,
23 assertions: [ok],
24 },
25 })
26}

Trusted by the teams that carry the pager

Vercel
Carhartt
CrowdStrike
Airbus
Fanatics
Mistral
ServiceNow
GoFundMe
Hopper
1Password
Fastly
Total Wine
“Few things in site reliability are as frustrating as having a system go down only to learn that your backup scripts stopped running at some point and you didn't notice. Checkly's heartbeat feature made it extremely simple to monitor my backup process for reliable execution.”
Dan Subak·Software Engineer, Memfault

The three ways monitoring breaks down at scale

Not because anyone is careless. Because monitors managed by hand always end up like this.

click-ops

Monitors drift

Checks built in a UI two years ago by someone who left. No version history, no review, no owner. The dashboard is green and nobody trusts it.

coverage

New services ship unmonitored

Teams ship weekly; monitors get added when someone remembers. The gap surfaces in the incident review, not before it.

03:14 a.m.

On-call stops believing alerts

A network blip in one region pages the whole rotation. After the third false alarm, alerts get muted. The real one lands in silence.

Checkly treats monitors like the rest of your infrastructure: declared in code, reviewed in pull requests, deployed from CI, and confirmed across regions before anyone gets paged. The alert channel, the status page, and the trace are constructs in the same project, so the whole incident path is one thing you version rather than four tools you wire together.

“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

Only page on-call when it's real

You define the retry strategy: fixed, linear, or exponential backoff, how many attempts, and whether the retry runs from the same region or a different one. You define the escalation policy that decides when a failure is worth a page. When one is, it lands in the tools your rotation already runs on, and the same check opens the incident on your status page so customers are not waiting on someone to remember them.

  • Retries with fixed, linear, or exponential backoff, cross-region
  • Alert on the first failed run, the third, or after minutes of sustained failure
  • PagerDuty and Opsgenie incidents trigger and auto-resolve with your policies
  • Channels subscribe per alert type: failure, degradation, recovery, SSL expiry
  • triggerIncident opens and closes the status page incident from the same check

More on alerting →

__checks__/oncall.check.ts
1// __checks__/oncall.check.ts
2import {
3 ApiCheck, PagerdutyAlertChannel, SlackAlertChannel,
4 RetryStrategyBuilder, AlertEscalationBuilder, StatusPageService,
5} from 'checkly/constructs'
6
7const pagerduty = new PagerdutyAlertChannel('pd-sre', {
8 serviceName: 'acme-prod',
9 serviceKey: process.env.PAGERDUTY_SERVICE_KEY!,
10})
11
12const slackOncall = new SlackAlertChannel('slack-sre', {
13 url: new URL(process.env.SLACK_WEBHOOK_URL!),
14 channel: '#sre-oncall',
15 sendDegraded: true,
16})
17
18// The same failure your customers are about to notice
19const checkoutSvc = new StatusPageService('checkout', {
20 name: 'Checkout',
21})
22
23new ApiCheck('checkout-api', {
24 name: 'Checkout API',
25 request: { method: 'GET', url: 'https://api.acme.com/checkout' },
26
27 // Confirm across regions before anyone is paged
28 retryStrategy: RetryStrategyBuilder.exponentialStrategy({
29 baseBackoffSeconds: 5,
30 maxRetries: 2,
31 sameRegion: false,
32 }),
33
34 // Page on the 2nd consecutive failed run, remind every 10 minutes
35 alertEscalationPolicy: AlertEscalationBuilder.runBasedEscalation(2, {
36 interval: 10,
37 amount: 3,
38 }),
39
40 alertChannels: [pagerduty, slackOncall],
41
42 // Opens when it fails, resolves when it recovers. Nobody posts it.
43 triggerIncident: {
44 service: checkoutSvc,
45 severity: 'MAJOR',
46 name: 'Checkout degraded',
47 description: 'The Checkout API check is failing from multiple regions.',
48 notifySubscribers: true,
49 },
50})

Already use Terraform for IaC? Use it for MaC.

Checkly fits the workflow you standardized on instead of asking for a new one. The official Terraform provider manages checks, groups, and alert channels in the same plan and apply cycle as the rest of your infrastructure.

  • Official Terraform provider, plus a Pulumi provider and a documented REST API
  • Typed TypeScript constructs with npx checkly test and deploy, built for CI
  • npx checkly import adopts your existing checks incrementally, nothing recreated
  • Full parity between code and UI, so click-first teammates stay unblocked
monitoring.tf
1resource "checkly_check" "checkout_api" {
2 name = "Checkout API"
3 type = "API"
4 activated = true
5 frequency = 1
6 locations = ["us-east-1", "eu-west-1"]
7
8 request {
9 url = "https://api.acme.com/checkout"
10 assertion {
11 source = "STATUS_CODE"
12 comparison = "EQUALS"
13 target = "200"
14 }
15 }
16}

Monitor the services your users never see

Public probes can't reach the internal APIs, admin panels, and staging environments your teams depend on. Run the Checkly agent anywhere Docker runs, and those systems get the same checks, alerting, and history as everything public.

  • One lightweight agent container inside your VPC, cluster, or data center
  • Checks execute from within your network; traffic never leaves it
  • Run multiple agents per location for redundancy and horizontal scale
  • Same constructs, same alerting, same dashboards as public checks
__checks__/private-location.check.ts
1// 1. Run the agent anywhere Docker runs, inside your network:
2// docker run -e API_KEY="pl_..." -d checkly/agent:latest
3
4// 2. Point checks at it. Traffic never leaves your network.
5import { ApiCheck, PrivateLocation } from 'checkly/constructs'
6
7const vpcUsEast = new PrivateLocation('vpc-us-east', {
8 name: 'AWS us-east-1 VPC',
9 slugName: 'vpc-us-east',
10})
11
12new ApiCheck('billing-internal', {
13 name: 'Billing API (internal)',
14 privateLocations: [vpcUsEast],
15 request: {
16 method: 'GET',
17 url: 'http://billing.internal:8080/health',
18 },
19})

Hand on-call a hypothesis, not a dashboard

The expensive part of an incident is rarely the fix. It is the twenty minutes spent working out which service to open. Checks emit OpenTelemetry spans, so a failed run links to the request behind it, and Rocky AI reads the two together and says what broke. Often the answer is that it was not you.

  • OpenTelemetry spans correlate every failed run to the backend request behind it
  • Rocky AI names the likely cause, including when it is a third-party dependency
  • Export the same traces to Grafana Tempo, Honeycomb, or Datadog
  • Screenshot, video replay, and logs attached to the run, not reconstructed later

How traces connect a check to a span →

It plugs into the stack you already run

Checkly is the synthetic layer, not another silo. Results flow out to your metrics, traces, and incident tooling through native integrations and raw webhooks.

Prometheus

An exporter endpoint you scrape. Check status, degraded state, and per-region response times land next to the rest of your metrics.

Learn more

OpenTelemetry

Correlate failed checks with backend traces over standard OTel. Export the same traces to Grafana Tempo, Honeycomb, or Datadog.

Learn more
Terraform

Terraform

The official provider. Manage checks, groups, and alert channels next to the rest of your infrastructure.

Learn more
PagerDuty

PagerDuty

Trigger and auto-resolve incidents on your existing escalation policies.

Learn more
Opsgenie

Opsgenie

Open alerts with priorities mapped to your on-call rotations.

Learn more

Webhooks + 18 channels

Slack, Teams, SMS, phone calls, incident.io, Rootly, FireHydrant, and raw webhooks with full payload control for everything else.

Learn more

Status pages

Public or private status pages on your own domain, driven by the checks you already run. Incidents open and resolve without anyone posting an update by hand.

Learn more

Dashboards

Shareable, tag-filtered views of uptime and latency. One per service tier, or one for whoever asks how last quarter went.

Learn more

Rocky AI

Reads the failed run and its trace, then names the likely cause in plain language so the rotation starts from a hypothesis.

Learn more

One incident, end to end

Everything on this page in the order it actually happens. The only human in it is the one who picks up the page at 00:41, and by then the customers have been told and the cause has a name.

  1. 00:00

    The check fails

    detect

    Checkout API returns 503 from us-east-1. Nothing has been sent to anyone yet.

  2. 00:05

    It gets retried, elsewhere

    detect

    Exponential backoff, cross-region. A blip would have resolved itself here and the rotation would never have known.

  3. 00:41

    The page goes out

    communicate

    Second consecutive failure meets the escalation policy. PagerDuty opens an incident, #sre-oncall gets the failing assertion and a link to the run.

  4. 00:41

    Customers are told, by the check

    communicate

    The same check opens the incident on status.acme.com and notifies subscribers. No one wrote it, which is why it actually happens at 00:41 and not at 00:55.

  5. 01:12

    The cause has a name

    resolve

    The trace puts the latency in the payments gateway, not your service. Rocky AI says so in a sentence, before anyone has opened a dashboard.

  6. on recovery

    The loop closes itself

    communicate

    When the check goes green the PagerDuty incident auto-resolves and the status page incident closes itself.

Reliability people, on Checkly

“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

“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

“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

“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

“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 incredible: it combines Pingdom, Ghost Inspector, and Assertible in the same app, and the insights are much more detailed.”

Leo Lamprecht

SVP Product · Vercel

Frequently asked questions

How Checkly fits an SRE practice: the stack, the workflow, and the on-call rotation.

No. Checkly is the synthetic monitoring layer that sits beside your metrics and logging stack, and it is built to feed it: a Prometheus exporter for check status and response times, OpenTelemetry traces in and out, and webhooks for everything else. Many teams run Checkly next to Datadog or a Grafana stack and route its verified alerts into the same on-call tooling.

Yes. The official Terraform provider covers checks, check groups, alert channels, private locations, and more, so monitors live in the same plan/apply workflow as the rest of your infrastructure. The TypeScript CLI and a Pulumi provider are equal citizens, and everything has full parity with the web app.

Two layers before anyone is paged. Retries: every failed run can be retried with fixed, linear, or exponential backoff, from the same region or a different one, so transient blips resolve themselves. Escalation policies: alert on the first failed run, the third, or after minutes of sustained failure, with reminders on your cadence. For checks running in parallel across locations, you can also require a percentage of locations to fail before alerting.

Yes. Private Locations run a lightweight agent container inside your VPC, Kubernetes cluster, or on-premises network. Checks execute from within your infrastructure, traffic stays inside your network, and you can run multiple agents per location for redundancy and horizontal scale.

Run npx checkly import. It pulls your existing checks, groups, and alert channels into TypeScript constructs so you can move to the code workflow incrementally, without recreating anything. Code and UI keep full parity, so teams can migrate service by service.

PagerDuty and Opsgenie natively, with incidents that trigger and auto-resolve. incident.io, Rootly, and FireHydrant kick off incident workflows from failed checks. In total there are 18+ alert channels including Slack, Microsoft Teams, SMS, and phone calls, plus fully customizable webhooks.

No. Checkly status pages run on your own domain, public or private, and they are driven by the checks you already have. Incidents open when a check fails and resolve when it recovers, so customer communication stops being a manual step someone remembers during an incident. That is usually one fewer vendor and one fewer place for the truth to drift.

It reads the failed run the way an engineer would: the error, the screenshot, the timing, and the OpenTelemetry trace correlated to that run. It comes back with a plain-language root cause, including when the fault is in a third-party dependency rather than your own code. On-call opens the alert with a hypothesis already attached instead of starting from a blank dashboard.

Put your monitors where your code lives

npm install, define a check, open a pull request. Your first monitor can be running from CI this afternoon.

Start for freeBook a demo