Systems that can never be down, checked every ten seconds

API checks run as often as every 10 seconds, and full browser flows every minute. Set a check or group to run in parallel and every location executes on every interval instead of rotating through them, so a failure in one region surfaces within an interval rather than after a full rotation. Retries and a parallel failure threshold keep a single unhappy location from paging anyone.

Yes. Browser checks run real Playwright specs, so one check can sign in, load a balance, submit a transfer, complete a second factor, and assert on the confirmation. Every step is timed separately, which is how you find out the ledger call got slow before it turns into a failed transaction. Specs you already run in CI can be promoted to monitors without a rewrite.

Yes, using private locations. You run a lightweight agent container inside your own VPC, cluster, or data center, and checks assigned to that location execute from within your network. Internal APIs, core services, and admin tooling get the same checks, alerting, and history as anything public.

Yes, and on this kind of service it matters more than the up/down signal. Each check carries both a degraded threshold and a maximum response time, so an endpoint that answers correctly but too slowly raises a degradation alert rather than a failure. Degraded and failed can route to entirely different channels and schedules.

Yes, and generating them is the normal way to get there. Checks are code, so one payment endpoint multiplied by corridor, region, and tenant is a loop rather than an afternoon of clicking. The Terraform and Pulumi providers manage checks, groups, and alert channels through the same plan and apply cycle as the rest of your infrastructure, and every change to a threshold arrives as a reviewed commit.

The measurement comes from outside your infrastructure, on a fixed schedule, from locations you choose, which is what makes it usable as evidence rather than self-reporting. Dashboards show per-region history including p95 and p99 response times, and status pages publish the checks you select on your own domain.

Yes. Status pages can be private rather than public, which is the common setup when availability is contractual and shared with named partners rather than published to the internet. Either way the page runs on your own domain and is driven by the checks themselves: the incident opens when a check fails, notifies subscribers, and resolves when it recovers, so nobody is writing customer updates by hand mid-incident.

Traces and Rocky AI. Checks emit OpenTelemetry spans, so a failing transfer links to the ledger call, fraud check, or third-party rail behind it instead of leaving you to guess which system to open. Rocky AI reads the failed run alongside that trace and returns a plain-language cause, including when the fault is in a provider rather than your own stack. At this volume that first correct guess is most of the incident.

Our security page covers how Checkly handles data, credentials, and access, and is the right starting point for a vendor review. For specifics your risk or procurement team needs in writing, talk to sales and we will route the question to the people who own the answer.