Checkly

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me synthetic monitoring that replaces Checkly: real browser journeys on a schedule, from more than one place, with a screenshot and a trace when they fail.

STACK
- Node 20+ with Fastify for the control plane
- SQLite through better-sqlite3, WAL mode
- Playwright for browser checks, plain fetch for API checks
- Runners as small agents that poll the control plane, so a second region is one more VPS
- Caddy in front

THE DATA MODEL
- checks: id, name, kind, script_path, config_json, schedule_seconds, regions_json, timeout_ms, retries, degraded_ms, is_active, muted_until
- runs: id, check_id, region, status, started_at, ended_at, duration_ms, error_kind, error_message, attempt, artifacts_path
- steps: id, run_id, position, name, status, duration_ms, error_message — a journey fails at a step, and that is what you need to know
- assertions: id, run_id, kind, target, expected, actual, passed
- incidents: id, check_id, opened_at, closed_at, cause_run_id, region_scope, notified_at
- alerts: id, incident_id, channel, target, sent_at, acknowledged_at
- status_pages, components, and a mapping from checks to components
- Runs are append-only and retained in full for a window, then reduced to per-hour summaries — but the summary is computed from the rows, never stored as the only record within the window

CHECK KINDS
- API check: a request or a sequence of them, with assertions on status, headers, body via JSON path, and response time
- Browser check: a Playwright script committed as a file, running a real journey — sign in, search, add to basket, check out
- Ping and TCP checks for the simple cases
- Multistep API checks where a value from one response is used in the next, which is most real API testing

RUNNING FROM SEVERAL PLACES
- A runner is a small process with a region name and a token; it long-polls for work, runs it, and posts back the result with artifacts
- The control plane never runs checks itself, so the machine that decides is not the machine that can be busy
- A failure in one region and a success in another is a network event, not an outage, and the incident logic must know the difference: open an incident only when a configurable number of regions agree, unless the check is marked single-region
- Runner health is itself monitored: a region that stops reporting is an alert, not silence

FAILURE ARTIFACTS, WHICH IS WHY BROWSER CHECKS ARE WORTH IT
- On failure: a screenshot at the failing step, the full trace, the console log, the network log with timings, and the HTML at the moment it broke
- Kept for failures always, for successes only on demand — traces are large
- The run page shows the step timeline, then the screenshot, then the trace. A failure you cannot see is a failure you will debug by rerunning it by hand

ALERTING WITHOUT NOISE
- Escalation: notify after N consecutive failures, not the first, configurable per check
- Channels: email, webhook, chat, and a shell command for anything else
- Recovery notifications, always, in the same channel
- Muting with an end time, never indefinitely
- A daily digest of degraded checks — the ones that pass but are getting slower, which is the failure you would otherwise find from a customer

PERFORMANCE OVER TIME
- Duration percentiles per check per region, computed at query time
- A degraded threshold separate from the timeout, so 'still works, twice as slow' is visible
- Charts as inline SVG, drawn by hand

STATUS PAGE
- Components mapped to checks, uptime over 90 days computed from runs, incidents with a written update history
- On its own subdomain and, ideally, on a different machine — a status page hosted on the thing it reports on is a status page that goes down with it. Say that in the README

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, RUNNER_TOKEN_SALT, SMTP_URL, SESSION_SECRET, ARTIFACT_PATH
- Migrations on boot, each once
- Secrets for check scripts stored encrypted and injected as environment variables at run time, never written to a log or an artifact
- Backup of the database nightly; artifacts pruned on a schedule
- Health endpoint

WHAT MATTERS MOST
The runner protocol and the multi-region incident rule. Build those first and run one browser check every five minutes for a week against a real site. A monitor that pages you for a hiccup in one region gets muted, and a muted monitor is worse than none.

Give me the repository, the runner agent, migrations, .env.example, two seed checks, and a README with deploy steps for the control plane and for a second region.