Reliability your engineers and their agents build together

Monitors are code that lives in each service’s repo, so ownership follows the same mechanics as the rest of the codebase: CODEOWNERS assigns reviewers, changes go through pull requests, and git history answers who changed what and why. Check groups and tags map services to teams inside Checkly, and each group routes alerts to its own channels.

Dashboard-managed monitors depend on individual accounts and individual memory: they drift, and they orphan when people leave. Code-managed monitors are reviewable, diffable, and revertible, and they survive team changes because they belong to the repo, not to a person. The web UI keeps full parity for anyone who prefers it, so nothing is lost for click-first teammates.

Incremental. npx checkly import pulls existing checks, groups, and alert channels into TypeScript constructs, so teams adopt the code workflow service by service without recreating anything. There is no big-bang migration and no gap in coverage while you switch.

Failures are retried with backoff, from the same region or a different one, and measured against an escalation policy before anyone is paged. You decide whether a page fires on the first failed run, the third, or after minutes of sustained failure. The pages that get through are confirmed, and they go to the team that owns the failing service, not to whoever is listed on a stale rota.

Yes. Dashboards give you shareable, tag-filtered views per team or per tier. Status pages communicate incidents to customers from the same checks that page your engineers. And the Prometheus exporter feeds check status and response times into the metrics stack your existing reporting is built on.

The checks do. Status pages run on your own domain, public or private, and the services on them are wired to the checks that page your engineers. When a check fails the incident opens and subscribers are notified; when it recovers the incident closes. That removes the step teams most often skip under pressure, and it means support and engineering are working from the same status rather than two.

Cutting the time spent establishing what broke. Traces connect the failing check to the backend span behind it, so nobody starts by guessing which service to open. Rocky AI reads the failed run and that trace together and returns a plain-language root cause, including when the fault sits in a third-party dependency. Whoever picks up the page starts from a hypothesis instead of a blank dashboard, and retros get shorter for the same reason.

Mostly no. Checks are TypeScript, browser checks are standard @playwright/test, and everything runs through the CI system you already have. For most teams the learning curve is an afternoon, and engineers tend to prefer it to clicking through a monitoring UI.