English for Checkly Monitoring Developers
Vocabulary for developers using Checkly — checks-as-code, uptime alerts, browser checks, assertions, and monitoring in CI — for teams discussing synthetic monitoring in English.
Checkly is a synthetic monitoring platform built around “checks-as-code” — you define API and browser checks in your own repository using TypeScript or JavaScript, version them alongside your application code, and run them both on a schedule and inside CI. Its vocabulary sits at the intersection of testing and monitoring, which trips up teams used to thinking of those as separate disciplines. Here’s the English to talk about it clearly.
Checks-as-Code
Checks-as-code — defining monitoring checks in source-controlled files rather than clicking through a dashboard UI, so checks get code review, versioning, and CI integration like any other code. “Every new API endpoint ships with a matching checks-as-code file in the same PR — reviewers can see the monitoring alongside the feature that needs it.”
Check — a single, scheduled test of a specific endpoint or user flow, run from geographically distributed locations to catch regional outages. “We added a check for the checkout API specifically, separate from the general health check, because checkout failing silently is a much bigger deal than a slow static page.”
Check group — a collection of related checks that share configuration (alert channels, locations, environment variables), used to avoid repeating the same settings across many checks. “All the payment-related checks live in one check group, so if we need to add a new alert channel, we set it once instead of updating a dozen checks.”
Types of Checks
API Check
An API check sends a request to a specific endpoint and validates the response, useful for verifying backend correctness without a full browser.
“The API check hits
/healthevery minute from six regions — if three of them start failing, we know it’s a regional network issue, not the app itself.”
Browser Check
A browser check runs a real, scripted user flow in a headless browser (login, add to cart, checkout) to catch issues that only show up in the rendered UI.
“The browser check caught a broken ‘add to cart’ button that the API checks completely missed, since the API itself was returning a healthy 200.”
Assertion
An assertion is a specific condition a check must satisfy to pass — a status code, a response time threshold, or the presence of certain text on a rendered page.
“We added an assertion on response time under 800ms, not just status code 200 — a technically successful but slow response should still trigger an alert.”
Alerting and Reliability
Uptime alert — a notification triggered when a check fails, typically after a configurable number of consecutive failures to avoid paging on a single flaky blip.
“We set the uptime alert to fire after two consecutive failures instead of one — that cut false-positive pages by more than half.”
Alert channel — the destination a failed check’s notification is routed to, like Slack, PagerDuty, or email, configurable per check or check group.
“Payment checks page on-call through the PagerDuty alert channel, while marketing page checks just post to a low-priority Slack channel.”
Monitoring as code in CI — running the same check definitions as part of the deployment pipeline, so a broken flow can block a release before it reaches real users.
“We run the critical browser checks as a CI gate before promoting to production — if checkout is broken, the deploy simply doesn’t go through.”
Explaining Checkly to a Team
| Situation | Phrase |
|---|---|
| Justifying checks-as-code | ”Keeping checks in the repo means they get reviewed and versioned like the feature they’re monitoring, instead of drifting silently in a separate dashboard.” |
| Explaining an alert threshold | ”We require two consecutive failures before paging — that filters out one-off network blips without hiding a real outage.” |
| Describing check coverage | ”API checks confirm the backend is healthy, but the browser check is what actually caught the broken button — we need both.” |
| Discussing CI integration | ”The critical-path browser check runs as a deploy gate now, so a broken checkout flow can’t reach production undetected.” |
Common Mistakes
- Relying only on API checks and assuming the UI is fine — a healthy backend response doesn’t guarantee the frontend renders or wires it up correctly.
- Setting alert thresholds too sensitive (one failure = page) and causing alert fatigue that leads to real outages being ignored.
- Treating checks-as-code files as write-once — like any test, they need updating when the flow they monitor changes, or they start giving false confidence.
Practice Exercise
- Explain, in two sentences, why a team might need both an API check and a browser check for the same feature.
- Write a short PR description for adding a new browser check to a check group, including an assertion on load time.
- Draft a message justifying adding a critical-path check as a CI gate before production deploys.