Checkly Synthetic Monitoring: Complete Guide

Synthetic monitoring means running scripted checks against your application on a schedule, from real locations around the world, before your users notice something is broken. Checkly is one of the most developer-friendly platforms for doing exactly that.

This guide covers everything: what Checkly actually is, how it's structured, the difference between its two check types, how scheduling and locations work, and how to read your dashboards. No marketing fluff — just the architecture and how it maps to real problems.

What Checkly Is (and Is Not)

Checkly is a synthetic monitoring platform. It does not watch your logs, aggregate metrics from your servers, or track APM traces. It runs checks — HTTP requests or Playwright browser scripts — from multiple geographic locations on a schedule, records whether they passed or failed, measures response time, and fires alerts when things go wrong.

This is fundamentally different from:

• Real User Monitoring (RUM): watches actual user sessions
• APM (Application Performance Monitoring): instruments your server-side code
• Log aggregation: ingests and searches application logs

Checkly fills the gap between "deploy succeeded" and "users are actually happy." It tells you whether your login flow works from Tokyo right now, and whether your API responds in under 500ms from Frankfurt.

Core Architecture

Checks

A check is the atomic unit in Checkly. There are two types:

API Checks — HTTP requests with assertions. You define a URL, method, headers, body, and a set of assertions (status code equals 200, response time under 2000ms, JSON body contains a specific value). Checkly runs this request from your chosen locations and fails the check if any assertion fails.

Browser Checks — Playwright scripts that run in a real Chromium browser. You write JavaScript or TypeScript that navigates your application, interacts with it, and asserts on the result. These are heavier than API checks but catch frontend-specific failures: JavaScript errors, broken rendering, flows that depend on cookies or session state.

Check Groups

Groups let you organize checks that share configuration — base URL, environment variables, alert channels, and tags. If you're monitoring a single service with 15 endpoints, put them all in a group. Change the base URL in one place when you promote to production; all checks in the group pick it up automatically.

Groups also share alert channels and retry logic. Define once, inherit everywhere.

Alert Channels

An alert channel is where Checkly sends notifications when a check fails (or recovers). Supported channels:

• Email — individual addresses or distribution lists
• Slack — webhook-based, configurable per workspace and channel
• PagerDuty — integrates with on-call schedules and escalation policies
• Opsgenie — similar to PagerDuty
• Webhook — POST to any URL, custom payload, for custom integrations
• SMS — via Twilio (requires your own Twilio credentials)

Each channel can be configured with alert thresholds: only fire after N consecutive failures, or send recovery notifications. This prevents alert fatigue from transient blips.

Environments and Variables

Checkly supports environment variables at three levels:

1. Account-level — shared across all checks (e.g., API_KEY)
2. Group-level — shared within a group (e.g., BASE_URL per environment)
3. Check-level — specific to a single check

Variables can be marked as secret (encrypted at rest, not shown in the UI after saving). Use this for API keys, tokens, and passwords.

You can maintain separate variable sets for staging and production, then switch which set a group uses — a lightweight way to run the same checks against multiple environments.

API Checks vs Browser Checks

When to Use API Checks

• Monitoring REST or GraphQL endpoints
• Checking authentication flows (token exchange, OAuth callback)
• Verifying webhook delivery
• Health check endpoints (/health, /status)
• Any check where the thing being tested is a network response, not a UI

API checks are cheap, fast, and easy to maintain. They run in milliseconds. Write them liberally.

When to Use Browser Checks

• Critical user flows: login, checkout, signup
• Pages where JavaScript renders the content (SPAs, React apps)
• Multi-step flows that require session state
• Forms that submit via JavaScript
• Any check where you need to assert on what a user actually sees

Browser checks take 10-60 seconds to run. They're more expensive in terms of check minutes and more brittle (DOM changes break them). Use them for critical paths, not every page on your site.

A Concrete Example

Bad approach: use a browser check to verify your API returns 200. That's wasted compute.

Good approach: use an API check for GET /api/products, and a browser check for "user can browse products and add one to cart." The API check catches backend failures instantly. The browser check catches failures in the frontend rendering and cart logic.

Scheduling and Locations

Scheduling

Every check runs on a schedule. Available intervals range from every 10 seconds (on higher plans) to every 24 hours. Common choices:

• 1 minute for critical production endpoints
• 5 minutes for secondary endpoints or slower browser checks
• 10-15 minutes for checks that are expensive to run (long Playwright scripts)

More frequent = faster detection = higher cost. Set the frequency based on how quickly you need to know when something breaks, not on some default.

Locations

Checkly runs checks from global locations — AWS regions distributed across North America, Europe, Asia-Pacific, and South America. Examples: us-east-1, eu-west-1, ap-southeast-1, sa-east-1.

You select which locations each check (or group) runs from. A check set to run from 5 locations every 5 minutes actually runs 5 times per 5-minute window, once from each location.

Why this matters: a failure from one location but not others often indicates a regional DNS or CDN issue, not a full outage. A failure from all locations simultaneously is a genuine outage. Checkly's dashboard makes this distinction visible.

Retries

Checks support automatic retries on failure. If a check fails, Checkly can retry it once (or twice) from the same or a different location before triggering an alert. This filters out transient network errors without adding alert delay for real failures.

Configure retry strategy per check or per group. For most checks, one retry from a different location is a reasonable default.

Dashboards

Checkly provides two dashboard surfaces:

Internal Dashboard (Web UI)

The main Checkly dashboard shows:

• Check list with current status (passing/failing/degraded), last run time, and p95 response time
• Check detail with a timeline of recent runs, per-location status, response time graphs, and failure details
• Group view aggregated status for all checks in a group

For failing checks, you get the full response body, headers, error message, and (for browser checks) screenshots taken at the point of failure plus a trace of the Playwright execution.

Public Status Pages

Checkly can generate a public status page — a hosted page you share with customers. It shows current status and uptime history for selected checks. You control which checks appear on the public page; you don't have to expose everything.

Status pages support custom domains and basic branding. They're not the most customizable status pages on the market, but they're good enough for most SaaS products.

Metrics Available

For each check you get:

• Availability (% of runs that passed) over configurable time windows
• Response time (avg, p50, p75, p95, p99) per location
• Failure rate and failure breakdown by location
• Check run history — individual runs with pass/fail and response time

These metrics feed into SLA reporting. If you've committed to 99.9% uptime to customers, Checkly's data is the source of truth for your synthetic availability.

What Checkly Doesn't Do

Know the limits before you commit:

• No log ingestion — it doesn't know why your server returned 500, just that it did
• No distributed tracing — no correlation with backend spans
• No infrastructure metrics — CPU, memory, disk are not here
• No real user data — it can't tell you what your slowest real-user sessions looked like

Checkly pairs well with an observability stack (Datadog, Grafana, etc.) — it detects the problem, your observability tools help you diagnose it.

Getting Started Checklist

1. Create a Checkly account (free tier: 3 checks, 10k check runs/month)
2. Create your first API check against a public endpoint
3. Add an assertion (status == 200, response time < 2000ms)
4. Add an alert channel (Slack or email)
5. Set a schedule (5 minutes, two locations)
6. Watch it run, then break something in your staging environment to see the alert fire

Once you've done this once, the pattern clicks and you'll know exactly where to add checks across your stack.