Getting Started with Checkly: Your First Monitor in 10 Minutes
Ten minutes. That's genuinely how long it takes to go from zero to a running monitor in Checkly. This guide walks through every step: account setup, first API check, first browser check with Playwright, and alerts. No prerequisites except a browser and an endpoint to monitor.
Step 1: Account Setup
Go to app.checklyhq.com and create an account. The free tier gives you 3 checks and 10,000 check runs per month — enough to follow this guide and monitor a few endpoints.
After signup you'll land in the dashboard. The onboarding wizard is optional; skip it if you want to follow this guide instead.
Step 2: Create Your First API Check
API checks are the simplest place to start. They send an HTTP request and assert on the response.
- Click Checks in the left sidebar
- Click + New Check
- Select API Check
You'll see a form with the following sections:
Request configuration:
- Method:
GET - URL: use
https://api.checklyhq.com/public-stats(Checkly's own public API — always available, good for testing)
Assertions:
Click Add assertion and add two:
| Property | Comparison | Value |
|---|---|---|
| Status code | Equals | 200 |
| Response time | Less than | 2000 |
These two assertions cover the basics: the request succeeds and it's fast enough to be usable.
Schedule and locations:
- Frequency:
5 minutes - Locations: pick two —
us-east-1andeu-west-1
Running from two locations means you'll catch regional issues. One location failing while the other passes signals a network or CDN problem, not a full outage.
Name and save:
Name it something descriptive: Public Stats API - GET. Click Save Check.
Checkly will run it immediately. After 10-15 seconds, refresh and you'll see the first result: green (passing) with a response time in milliseconds.
Step 3: Read the Check Result
Click into the check. You'll see:
- Status: Passing
- Last run: timestamp and which locations ran it
- Response time graph: empty until a few runs have accumulated
- Run details: expand the latest run to see the full HTTP response — status code, headers, body
Click Run Now to force an immediate run. Within seconds you'll see the result populate.
Step 4: Create Your First Browser Check
Browser checks run real Playwright scripts in a Chromium browser. They're how you verify that a user flow actually works end-to-end.
- Click + New Check
- Select Browser Check
The editor opens with a default script. Replace it with this:
const { chromium } = require('playwright');
const browser = await chromium.launch();
const page = await browser.newPage();
// Navigate to the page
await page.goto('https://checklyhq.com');
// Assert the page title contains "Checkly"
const title = await page.title();
if (!title.includes('Checkly')) {
throw new Error(`Expected title to include "Checkly", got: ${title}`);
}
// Assert a key element is visible
await page.waitForSelector('nav', { timeout: 5000 });
console.log('Check passed. Title:', title);
await browser.close();This is a minimal but real browser check: it opens a browser, loads a URL, asserts the title, and checks that navigation exists.
Schedule and locations:
- Frequency:
10 minutes(browser checks are slower and more expensive) - Locations:
us-east-1
Name it Checkly Homepage - Load Test and save.
Click Run Now to execute it immediately. You'll see the script output in the run details, including your console.log output, any screenshots (Checkly auto-captures one at the end), and the execution timeline.
Step 5: Write a More Realistic Browser Check
The previous check was educational. Here's a more useful pattern — checking a login flow on a staging environment:
const { chromium } = require('playwright');
const browser = await chromium.launch();
const context = await browser.newContext();
const page = await context.newPage();
try {
// Go to login page
await page.goto(process.env.BASE_URL + '/login');
// Fill in credentials from environment variables
await page.fill('input[name="email"]', process.env.TEST_EMAIL);
await page.fill('input[name="password"]', process.env.TEST_PASSWORD);
// Submit the form
await page.click('button[type="submit"]');
// Wait for redirect to dashboard
await page.waitForURL('**/dashboard', { timeout: 10000 });
// Assert dashboard element is visible
await page.waitForSelector('[data-testid="user-greeting"]', { timeout: 5000 });
console.log('Login flow passed');
} finally {
await browser.close();
}For this to work, you need environment variables set. Go to Account Settings → Environment Variables and add:
BASE_URL: your staging URL (e.g.,https://staging.myapp.com)TEST_EMAIL: a test account emailTEST_PASSWORD: the password (mark as secret)
Now this check runs every 10 minutes, logs in as your test user, and confirms the dashboard loads. If anything breaks in the login flow — backend error, form change, redirect issue — this check catches it within 10 minutes.
Step 6: Set Up Alerts
Checks without alerts are just dashboards you'll never look at. Set up an alert channel now.
- Go to Alert Channels in the left sidebar
- Click + New Alert Channel
- Choose your destination:
For Slack:
- Select Slack
- Click Connect Slack — this opens OAuth, select your workspace and channel
- Set alert conditions: "Send alert when check fails"
- Optionally: "Send alert when check recovers" (highly recommended — otherwise you don't know when an incident resolves)
For Email:
- Select Email
- Enter the address
- Configure the same alert/recovery settings
Attach the channel to your checks:
Go back to each check you created. In the check settings, scroll to Alert Channels and add the channel you just created. Save.
Now when a check fails, you'll get an alert within the next run interval (max 5 minutes for your API check, 10 for the browser check). When it recovers, you'll get a recovery notification.
Step 7: Verify the Alert Works
Don't wait for a real failure to discover your alerts are misconfigured. Test them now.
Option 1: Break the assertion intentionally. Edit your API check, change the status code assertion from 200 to 999. Save. Click Run Now. The check will fail. Wait for the alert.
Option 2: Use Checkly's test alert feature. In the Alert Channel settings, there's a Send Test Alert button. Click it to fire a test notification to your Slack or email without needing an actual failure.
After confirming the alert arrives, fix the assertion back to 200.
What You Have Now
After following this guide you have:
- An API check running every 5 minutes from two locations, alerting you if your endpoint returns a non-200 or takes over 2 seconds
- A browser check running every 10 minutes, verifying a real user flow in a real browser
- An alert channel sending failures and recoveries to Slack or email
This is a functioning synthetic monitoring setup. It's not comprehensive — you'll want more checks covering more flows — but the pattern is established.
Next Steps
From here:
- Add more API checks for every critical endpoint: authentication, data fetching, webhooks
- Add browser checks for checkout, signup, and any flow that generates revenue
- Create a Check Group for checks that share the same base URL and alert channel
- Set up a public status page if you have customers who care about uptime
- Integrate with CI/CD using the Checkly CLI (covered in a separate guide) to run checks as deployment gates
The monitoring setup compounds over time. Each check you add is another failure you'll catch before a user does.