SMF·CHECKLY
Can a prompt replace Checkly?
Monitoring & observability — synthetic monitoring as code
Exhibit tracking slip
Verdict
Checkly's idea is that a monitor is a test: it lives in your repository, it runs in CI, and it also runs every few minutes against production. Rebuilding that is a weekend, because Playwright does the hard part and a scheduler does the rest. It stays a kinda because the thing you cannot cheaply reproduce is running the same check from a dozen countries at once — that is rented machines in rented regions, and it is what separates "your site is down" from "your site is down in Sydney".
Exhibit A — The prompt
Received on31.07.2026Build synthetic monitoring where checks are code in the repository, not configuration in a dashboard.
Stack: Node with Playwright, plus a small scheduler and result store (Postgres). Docker Compose.
Check definition: a file in the repo exporting a name, a schedule, an expected maximum duration, and either an HTTP assertion or a Playwright script. Discover checks by globbing a directory — adding a file is adding a check, with no registration step.
Three run modes over the same definitions, which is the whole point:
1. **CI**: run every check against a preview environment. A failing check fails the build.
2. **Deploy gate**: after a production deploy, run the checks tagged critical and, if any fails, exit non-zero so the pipeline can roll back. Document how to wire that.
3. **Scheduled**: run on the declared interval against production, storing every result with duration, status and, on failure, the Playwright trace and a screenshot.
Results and alerting:
- A check alerts after N consecutive failures, not the first, because a single blip is noise. Make N per check.
- Recovery sends its own notification. An alert with no all-clear trains people to ignore alerts.
- Suppress alerts during a declared maintenance window.
- Store the duration series per check and alert on a degradation threshold too — a page that went from 400ms to 3s is not down, and it is the thing you actually want to know.
The honest limitation, in the README and in the interface: results are labelled with the location they ran from, and a single-location setup says so on the dashboard rather than implying global coverage.
A public status page generated from the check history, on its own static output so it stays up when your application does not.
Write tests for the consecutive-failure threshold, for maintenance-window suppression across a boundary, and for the deploy gate exiting non-zero on failure.
Do not build a browser-based check editor or visual regression diffing.Opening prefills the prompt — press enter to run it.
Exhibit B — What you lose
- B.1 checks running from many global locations in parallel
- B.2 the hosted runners and their capacity
- B.3 private locations for monitoring inside a network
- B.4 visual regression testing and screenshot diffing
- B.5 alerting that survives your own infrastructure being the thing that broke
Prior art
Exhibit C — Why people still pay: global check locations
Because a check that only runs from one place tells you about one place, and renting machines in ten regions to find out that Frankfurt is slow is not a weekend project.
Questions
Why does keeping checks in the repository matter?
Because a check written in a dashboard drifts from the application within two releases, and nobody reviews it. In the repo it changes in the same pull request as the feature it covers, and it gets reviewed like code.
Why alert only after consecutive failures?
Because a single failed request is usually the network, and paging on it teaches people to ignore the pager. Two or three in a row is a signal; one is weather.
How much does single-location monitoring miss?
Regional outages, CDN misconfiguration and latency for users far from your servers — a real category of problem that your one check will never see. Labelling the location on the dashboard at least stops the false confidence.
Why generate the status page as static output?
Because a status page served by the infrastructure it reports on goes down with it, which is exactly when people look at it. Static output on separate hosting is the whole trick.
Related tools
Receipt