Uptime Monitoring & Status Pages
Checkly
Rest of world Report an errorPanel rating · 6 judges · How to read the stars
Category median
Sovereignty: 1 of 6 dimensions proven
0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by Checkly Inc. · www.checklyhq.com
Report an error on this page Is this your product? →
Link to this page
Add ?theme=dark to the image address for dark backgrounds.
The badge shows the category and the month of the latest evaluation, and EU-Made where
that is the product’s provenance. It never shows a score.
Checkly at a glance
- Vendor
- Checkly Inc.
- Headquarters
- Incorporated in United States source, captured 1 Nov 2026
- Data hosting
- Not stated on the vendor’s pages as of 1 Nov 2026
- Free plan
- Not stated on the vendor’s pages as of 1 Nov 2026
- Panel verdict
- The AI panel rates Checkly 3.5/5, the mean of 6 judges. Checkly scores highest on checks and locations and pricing transparency (8 flat), with automation and teams close behind; persona-weighted totals range 6.4 to 7.5. how scores are made
- As of
- Vendor pages captured 1 Nov 2026; evaluated by the panel 2 Nov 2026. all sources
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
Checkly scores highest on checks and locations and pricing transparency (8 flat), with automation and teams close behind; persona-weighted totals range 6.4 to 7.5. Judges repeatedly name monitoring-as-code the strongest part: TypeScript constructs, Terraform and Pulumi providers, with CI gating. Eight monitor types plus Playwright browser checks run from 22 public locations, failures retried and confirmed from a second location before alerting. Weakest is sovereignty: the contracting party is Checkly Inc. of Boston under New York law, the security page states all data is stored in the European Union on AWS eu-west-1 (Ireland), check-result data possibly stored where the check ran, the disaster-recovery fallback is us-east-1, subprocessor locations are largely unstated, with no public information on an EU contracting entity. flagged splits flagged nothing; status pages spread widest, lower scores citing no public information on SMS or webhook subscribers or multiple languages, higher ones crediting tag-based incident automation and the published uptime formula. Reports and reliability reflects the terms' commercially reasonable efforts commitment and no public information on the vendor's own status page.
Speaks for it
- Checks, alert channels, escalation policies and status pages deploy as version-controlled TypeScript or Terraform with CI gating
- Eight monitor types plus Playwright browser checks run from 22 public locations, each failure confirmed from a second location before alerting
- Pricing pages state tier prices, extra monitors at $8 per 25, run overages, SMS and phone quotas per plan, and discounts up to 20% annual, 30% startup and 50% nonprofit
- Status-page automation rules open an incident from a tagged failing check, post the first update and auto-resolve on recovery
- Reporting covers P50, P95 and P99 percentiles, saved views, CSV export and an Analytics API, with retention stated per plan
Held against it
- On-call schedules, rotations, acknowledge-and-resolve and incident timelines show no public information and are delegated to PagerDuty or Opsgenie
- Contracting party is Checkly Inc. of Boston under New York law, disaster-recovery fallback is us-east-1, and subprocessor locations are largely unstated
- The terms commit only to commercially reasonable efforts to maintain availability, with no public information on an SLA with credits
- We found no public information on SCIM provisioning, exportable audit logs, granular per-resource roles or client sub-accounts with their own logins
- Status pages show no public information on SMS or webhook subscribers, per-component subscriptions, multiple languages or embeddable widgets
Best for
- Your team keeps infrastructure in Git and wants checks, alert channels and status pages deployed and gated as code
- You already run PagerDuty or Opsgenie for on-call rotations and want broad alert channels with run-based and time-based escalation feeding them
- You need to budget a year of monitoring from public prices: Starter at $24 per month and Team at $64 per month billed annually, extra monitors at $8 per 25, and a $0 Hobby tier with no credit card required
- You already use Playwright and want to port an existing test suite into scheduled production monitoring
Avoid if
- Your procurement requires an EU contracting party: the terms name Checkly Inc. of Boston under New York law
- You need the monitoring tool itself to run on-call schedules and rotations rather than forwarding to a separate tool
- Your contract requires an availability SLA with credits: the terms commit to commercially reasonable efforts to maintain availability
The scores
| Criterion | Panel median |
|---|---|
| Checks, locations & failure confirmation | 4.5 of 5 |
| Alerting, escalation & on-call | 3.5 of 5 |
| Status pages & incident communication | 3 of 5 |
| API, monitoring as code & team administration | 3.5 of 5 |
| Uptime reports, data & the vendor's own reliability | 3 of 5 |
| European sovereignty | 2.5 of 5 |
| Pricing transparency | 4 of 5 |
Checks, locations & failure confirmation
Show reasoningHide reasoning
How this is scored
What can be monitored and how reliably a failure is detected: HTTP(S) with status code and keyword checks, TCP and port, ping, DNS records, SSL certificate and domain expiry, cron jobs and heartbeats, multi-step API checks with assertions, browser or transaction checks of a login or checkout, the shortest check interval, the number and regions of probe locations, the re-check from a second location before an alert, timeouts and response time thresholds, and private locations inside the customer's own network.
0 — Runs no checks of its own; a status page or alerting tool that only receives signals from other monitors.
3 — HTTP checks of a URL at a fixed interval with an up or down result; keyword, SSL, cron and the probe locations are basic or not described.
5 — HTTP(S), keyword, TCP or port, ping and SSL expiry checks, cron or heartbeat monitoring, an interval of one minute or less, several named probe locations, a failure confirmed from a second location before alerting, and response times recorded per check.
8 — Multi-step API checks with assertions on headers and body, browser or transaction checks of a user flow, DNS and domain expiry checks, sub-minute intervals, probe locations listed by city with the confirmation logic documented, private locations or agents for internal services, and maintenance windows that pause checks.
10 — Coverage and accuracy a reliability team runs on: every check type above with code-based checks (for example Playwright or scripted tests) in version control, location-specific thresholds, false-positive handling and probe health published, and the detection method documented so a result can be reproduced.
The Agency Developer
With sixty client sites I need coverage and honest failure confirmation, and the documentation gives both: eight monitor types (URL, TCP, DNS, ICMP, SSL, gRPC, traceroute, heartbeat), dedicated certificate checks for expiry, chain validity, hostname match and minimum TLS version, intervals down to ten seconds (one second on request), 22 public locations across the Americas, Europe, the Middle East, Africa and Asia Pacific, plus private-location agents. Failures are retried and confirmed from a second location before anyone is alerted, TCP runs record DNS, connect and data phases separately, and browser checks are real Playwright we could import from our own test suite. We found no public information on domain-expiry checks, and locations are listed as regions rather than cities. 3 7 12 13 19
The SaaS Platform Engineer
Eight monitor types — URL, TCP, DNS, ICMP, gRPC, SSL, traceroute, heartbeat — plus Playwright browser checks and multistep API flows, at intervals down to every 10 seconds with 1-second available on request, from 22 public locations plus private agents, and failed checks are retried and confirmed from a second location before anyone gets an alert. Assertions, retry strategies with fixed, linear or exponential backoff, and a configurable percentage of parallel runs that must fail are all settable in Terraform next to the service. We found no public information on published probe health or alert settings that differ per location, which keeps this just short of the top. 3 7 8 12 13 19
The Customer Support Lead
Every check type a team like mine could need is documented — URL, TCP with payload assertions and separate DNS, connect and data timings, DNS records, ping, SSL expiry with chain and hostname validation, gRPC, traceroute and heartbeats — from 22 public locations plus private agents inside our own network, with failures retried and confirmed from a second location before anyone is paged. Checks run as often as every 10 seconds (1 second on request), and Playwright scripts live in version control with CI gating, which is how a reliability team works; we found no public information on published probe health or city-level location lists. 3 7 8 12 13 18
The E-Commerce Operations Manager
Eight monitor types from HTTPS and TCP to DNS, SSL expiry and traceroute, plus real Playwright browser checks that can walk my checkout and payment flow, running as often as every ten seconds from 22 public locations with a failed check retried and confirmed from a second location before anyone is paged. Private agents for internal services and maintenance windows are there too; the locations are described by region rather than city, and I found no published probe health or probe IP list to allow-list. 3 7 8 12 13
The Information Security Officer
Eight uptime monitor types plus Playwright browser and multistep API checks, from every ten seconds with one-second on request, retried and confirmed from a second location before anyone is alerted, with private agents for internal services and timezone-aware maintenance windows — and monitors defined as version-controlled TypeScript or Terraform, which is how a reliability team should run it. I could not find published probe health or limits set per location, and the location list gives regions and a count of 22 rather than cities. 3 4 7 8 12 13 15 19
The Skeptic
Every check type I probe for is documented — HTTP, TCP with payload and latency assertions, DNS, ping, SSL certificate expiry with chain and TLS-version checks, traceroute, gRPC and heartbeats — on intervals down to ten seconds with a one-second interval on request, and a failure retried and confirmed from a second location before anyone is paged. Playwright browser checks live in version control as TypeScript, latency is recorded per phase and per location, and private agents cover internal services behind an outbound-only container. Locations are counted as 22 across regions rather than listed by city, and we found no public information on published probe health, so I stop short of the top. 3 8 12 13 15 19
Alerting, escalation & on-call
Show reasoningHide reasoning
How this is scored
How the right person learns about a failure: alert channels (email, SMS, phone call, push app, Slack, Microsoft Teams, Telegram, webhooks), alerts to PagerDuty, Opsgenie or similar tools, escalation policies when an alert is not acknowledged, on-call schedules and rotations, acknowledge and resolve from the app, alert grouping and noise reduction, recovery notifications, maintenance windows that mute alerts, and whether SMS and calls are included or charged per message.
0 — No alerting at all; results can only be viewed in the dashboard.
3 — Email alerts and one or two chat integrations; escalation, phone calls and schedules are basic or not described.
5 — Email, SMS, a mobile push app, Slack, Microsoft Teams and webhooks, alerts forwarded to PagerDuty or Opsgenie, per-monitor alert contacts, recovery notifications, a delay or threshold before alerting, and maintenance windows that mute alerts.
8 — Phone call alerts, escalation policies with timeouts, on-call schedules and rotations with overrides, acknowledge and resolve from the app or chat, alert grouping, incident timelines with who did what, and the price of SMS and calls stated per country or included in the plan.
10 — On-call that replaces a separate incident tool: follow-the-sun schedules, escalation across teams, alert routing by service and severity, post-incident reviews generated from the timeline, and delivery of every alert channel monitored and reported.
The Agency Developer
The channel list is the widest I reviewed: email, SMS, phone calls, Slack, Microsoft Teams, Telegram, Discord and webhooks, plus forwarding to PagerDuty, Opsgenie, FireHydrant, incident.io and Rootly, with run-based and time-based escalation, reminders on a chosen cadence, recovery notifications, SSL-expiry alerts and maintenance windows that mute them. SMS and phone alerts are stated as monthly quotas per plan rather than per-message prices, and a notification log tracks delivery success per channel. We found no public information on on-call schedules and rotations, or on acknowledging and resolving from the app — the rotations live in the tools Checkly forwards to, which works for us since we already run PagerDuty. 4 6 8 14 15
The SaaS Platform Engineer
Phone calls, SMS, email, Slack, Microsoft Teams, Discord, Telegram and webhooks are all there, alongside forwarding to PagerDuty and Opsgenie with priority and region configuration, and escalation policies defined in code: alert after N failed runs or N minutes of sustained failure, reminders every 5 to 30 minutes until recovery, and a notification log tracking delivery per channel. SMS and phone alerts are quoted as included monthly quotas — 100 SMS on Starter, 200 SMS and 200 phone alerts on Team — rather than per-message prices. We found no public information on Checkly running its own on-call schedules and rotations, or on acknowledging and resolving alerts from the app or chat. 4 6 8 13 14 15
The Customer Support Lead
All the channels my nine people could need are there — email, SMS, phone calls, Slack, Microsoft Teams, Discord, Telegram, webhooks — plus forwarding into PagerDuty and Opsgenie with their on-call rotations, run-based and time-based escalation with reminders, recovery alerts, per-channel alert-type subscriptions and a notification log that tracks delivery success per channel. SMS and phone alerts come as stated monthly quotas (100 SMS on Starter, 200 SMS and 200 calls on Team); we found no public information on native on-call schedules with rotations, acknowledging from the app, or alert grouping. 6 8 12 14 15
The E-Commerce Operations Manager
SMS to the on-call phone and a real voice call for the alerts that must never be missed are in, with run-based and time-based escalation, reminders every 5 to 30 minutes, per-channel delivery logging, and stated monthly quotas (100 SMS on Starter, 200 on Team, phone alerts on Team). What I did not find is a native on-call schedule or rotation — those live in PagerDuty or Opsgenie — nor incident timelines, acknowledge-from-app, or a per-country price for messages beyond the monthly quota. 6 8 12 14 15
The Information Security Officer
The channel list is broad — email, SMS, phone calls, Slack, Teams, Telegram, webhooks and nine incident-management tools — with run-based and time-based escalation, reminders on a set cadence, recovery notices, maintenance windows and monthly SMS and phone quotas stated per plan, plus a notification delivery log per channel. What I did not find is on-call machinery inside the product: schedules, rotations, acknowledge-and-resolve, and a timeline of who did what are delegated to PagerDuty or Opsgenie, and for an outage record under NIS2 I want the acknowledgement trail held by the monitoring tool itself. 4 6 8 12 14 15
The Skeptic
Eighteen-plus channels including SMS, phone calls, Slack, Teams, Telegram and webhooks, routed to PagerDuty and Opsgenie, with run-based and time-based escalation, timed reminders, and monthly SMS and phone quotas stated per plan rather than buried in a fair-use clause — the notification log that tracks per-channel delivery success is an honest touch. Recovery notifications and maintenance windows are documented. But we found no public information on native on-call schedules and rotations, acknowledging and resolving from the app or chat, alert grouping, or incident timelines with who did what, so the on-call burden still lands on a separate tool. 6 8 14 15
Status pages & incident communication
Show reasoningHide reasoning
How this is scored
How customers and colleagues are told: public status pages on a custom domain with SSL, components and component groups fed automatically by monitors or set by hand, incident updates and scheduled maintenance announcements, subscribers notified by email, SMS, RSS or webhook, uptime history shown per component, private or password-protected pages for internal teams or single customers, branding and custom CSS, several languages, page templates, and how the status page itself stays online when the main product is down.
0 — No status page of any kind.
3 — A public status page listing monitors with their current state; custom domain, incident updates and subscribers are basic or not described.
5 — Public status pages on a custom domain, components linked to monitors, incident updates and scheduled maintenance, email subscribers, uptime history per component, the vendor's branding removable, and a password-protected or private page option.
8 — Component groups, SMS, RSS and webhook subscribers with per-component subscriptions, private pages with single sign-on or IP restriction, several languages, incident templates, embeddable status widgets, audience-specific pages for single customers, and the status page hosting kept separate from the main service and documented.
10 — Incident communication end to end: incidents drafted from monitor events and approved by a person, updates published to the page, subscribers, chat and social channels at once, a full incident archive with post-mortems, status page uptime published, and accessibility of the page stated.
The Agency Developer
Pages run public or private on a custom domain via CNAME and TXT records, with services nested into groups, a 90-day history per component, incidents opened automatically by tag-matching rules or by hand, planned maintenance with reminders up to seven days ahead, and email subscribers alongside anonymous RSS, Atom and Slack feeds. Password protection and theme customization come with Team, white labeling and a custom number of pages with Enterprise, and a page built in the UI can be imported into the CLI and managed in Terraform — that per-client-page pattern is exactly what our client groups need. We found no public information on per-component subscriber choices, multiple languages, incident templates, embeddable widgets, or how the status page stays online independently of the main service. 5 8 16 17
The SaaS Platform Engineer
The automation rules are exactly what I want at 3 a.m.: a failing check carrying the rule's tag opens one incident on the components you listed, posts the first update, and resolves it when the check recovers, with planned maintenance shown on the page and able to suppress automated incidents. Custom domain with DNS verification, nested component groups, a documented uptime calculation, 90-day per-component history, verified email subscribers and anonymous RSS, Atom and Slack feeds are all documented, and password-protected private pages come on the Team and Enterprise plans. We found no public information on SMS or webhook subscribers, per-component subscription choices, incident templates, embeddable widgets or several languages. 5 8 16 17
The Customer Support Lead
This is the part I care about most and it holds up: pages served from our own domain via CNAME, services and groups my customers would recognise, a 90-day uptime history per component with a published calculation (major outage 100%, partial 30%, degraded 0%), email subscribers with verification, RSS, Atom and Slack feeds, password-protected private pages for the largest accounts, planned maintenance with seven-day reminders, and tag-based automation rules that open an incident and post the first update when a check fails. White labelling arrives on the Enterprise plan; we found no public information on per-component subscriptions, SMS subscribers, several languages, incident templates beyond the automation rule's first update, or how the status page hosting is kept separate from the main service. 5 8 16 17
The E-Commerce Operations Manager
Public pages on a custom domain with services and nested groups, automation rules that open an incident from a failing tagged check, post the first update and auto-resolve on recovery, email subscribers with verification plus RSS, Atom and Slack feeds, and a 90-day history per component with a documented uptime weighting. The captured pages show nothing on multiple languages, per-component subscriptions or embeddable widgets, and password protection as well as theme customisation only start on the Team tier. 5 16 17
The Information Security Officer
Public and private pages on a custom domain, services and nested groups with a documented 90-day uptime formula and its weighting, incidents opened automatically from tagged failing checks with manual follow-up updates, planned maintenance with reminders, and email, RSS, Atom and Slack subscribers with verification and unsubscribe. I found no single sign-on or IP restriction on private pages (password protection and Checkly account sign-in only), no per-component subscriptions, no multiple languages, no embeddable widget, and no statement of how the page stays up if the main service is down. 5 8 16 17
The Skeptic
Custom domain via CNAME and TXT, components and nested groups, incidents auto-opened from tagged failing checks, planned maintenance with reminders up to seven days ahead, email subscribers with verification plus anonymous RSS, Atom and Slack feeds, a 90-day uptime history per component with the weighting formula published outright, and password-protected private pages. That covers everything I ask of a mid-level offering. We found no public information on SMS or webhook subscribers, per-component subscriptions, single sign-on or IP restriction for private pages, several languages, embeddable widgets, or how the page itself stays online when the main product is down. 5 16 17
API, monitoring as code & team administration
Show reasoningHide reasoning
How this is scored
How the tool fits a team and a deployment pipeline: a documented REST API to create and read monitors, status pages and incidents, a Terraform provider, CLI or monitoring-as-code workflow, checks run from CI/CD before a deploy, bulk import of monitors, integrations with ticketing and chat tools, team members with roles, single sign-on (SAML) and SCIM, audit logs, several teams or client accounts in one organisation, white-label or client reporting for agencies, and two-factor authentication.
0 — No API, no team accounts; one login per account and monitors are set up only by hand.
3 — A web dashboard with a few team members; the API, roles and multi-client set-up are basic or not described.
5 — A documented REST API covering monitors and status pages, webhooks, team members with roles, two-factor authentication, bulk import or a CSV upload of monitors, and several projects, teams or client groups in one account.
8 — A Terraform provider or monitoring-as-code CLI with checks kept in version control, checks triggered from CI/CD, single sign-on (SAML), SCIM provisioning, audit logs, sub-accounts for clients with their own logins, and white-label client reports.
10 — Administration that scales across many teams and clients: every setting reachable by API and code with parity stated, granular roles per resource, SSO enforced with SCIM, audit logs exportable to a SIEM, and agency or reseller accounts with separate billing.
The Agency Developer
This is the monitoring-as-code story I would want for bulk setup: monitors, alert channels and status pages as TypeScript or JavaScript in Git, official Terraform and Pulumi providers, pull-request gating through GitHub Actions, full change history with rollback, and a REST API with an OpenAPI spec where everything the UI can do, the API can do. Multiple projects fit in one account, two-factor auth is on the pricing page, and SAML 2.0 with Microsoft AD arrives on Enterprise. We found no public information on team roles, SCIM provisioning, audit logs, client sub-accounts with their own logins, or white-label client reports — with sixty clients they would all sit inside our single account's projects. 1 7 11 18 19
The SaaS Platform Engineer
This is the strongest area: checks, groups, alert channels, escalation policies and entire status pages are TypeScript constructs or Terraform resources, `checkly test` gates pull requests through GitHub Checks, UI edits to code-managed checks open a pull request back, and the REST API is documented against an OpenAPI spec with stated parity with the web app. Multiple projects per account, role-based access control, MFA, and SAML 2.0 with Microsoft AD for Enterprise are documented. We found no public information on SCIM provisioning, exportable audit logs, or client sub-accounts with their own logins and white-label reports. 1 7 8 11 16 18 19
The Customer Support Lead
Monitoring as code is the strongest story on the evidence: a documented REST API with an OpenAPI spec and stated full parity with the web app, a TypeScript CLI plus Terraform and Pulumi providers that manage checks, alert channels and status pages, checks gating pull requests from CI, multiple projects in one account, and SAML single sign-on on Enterprise. We found no public information on SCIM provisioning, granular per-resource roles, client sub-accounts with their own logins, or audit logs exportable to a SIEM, so I cannot put it higher. 1 7 11 16 18 19
The E-Commerce Operations Manager
Monitoring as code is the strongest card: a documented REST API with an OpenAPI spec, official Terraform and Pulumi providers, the CLI with test and deploy commands gating releases through GitHub Actions, GitLab, Vercel or Jenkins, plus SAML 2.0 for Enterprise, multi-factor authentication and multiple projects per account. I found nothing on SCIM provisioning, organisation-wide audit logs, or agency or client sub-accounts with their own logins and white-label reporting. 1 7 8 11 18 19
The Information Security Officer
Monitoring as code is the strongest part: a TypeScript CLI with stated full parity in the web app, Terraform and Pulumi providers, checks gated in GitHub Actions, and a REST API with an OpenAPI spec. On the administration side I get SAML single sign-on on Enterprise, multi-factor auth, and multiple projects per account — but I found no SCIM provisioning, no in-app audit log I could export to a SIEM, no client sub-accounts and no granular per-resource roles; the change history and rollback live in the git project, not in the product. 1 7 8 11 18 19
The Skeptic
The monitoring-as-code story is the strongest part of this product: TypeScript constructs or Terraform and Pulumi providers kept in git, checks gated in CI via GitHub Actions, status pages importable from the UI into code, and a REST API with an OpenAPI spec where "Everything the UI can do, the API can do." SAML single sign-on is available for Enterprise, multi-factor auth exists, and multiple projects sit in one account with users per plan. But we found no public information on SCIM provisioning, account audit logs, client sub-accounts with their own logins, or granular roles — the difference between a team tool and an agency tool. 1 8 11 18 19
Uptime reports, data & the vendor's own reliability
Show reasoningHide reasoning
How this is scored
What the record is worth and whether the monitor itself can be trusted: uptime and SLA reports per monitor and period, response time charts and percentiles, scheduled reports by email, client-facing reports, how long check results and incident history are kept, export of results by CSV or API, the vendor's own public status page and incident history, its SLA, the probe IP addresses and user agent published for allow-listing, and an open-source or self-hosted edition.
0 — No history of any kind; only the current state is shown.
3 — An uptime percentage and a response time chart per monitor; retention, export and the vendor's own status are basic or not described.
5 — Uptime and response time reports per monitor and period, SLA reports, scheduled email reports, the retention period of check results stated, CSV or API export, the probe IPs published, and the vendor's own public status page.
8 — Response time percentiles and breakdowns (DNS, connect, TLS, first byte), client-ready branded reports, retention of a year or more stated per plan, a raw export of check results, the vendor's incident history and post-mortems public, and an SLA with credits published.
10 — A record that holds up in an audit: SLA calculations with their method stated, incident records suitable for ISO 27001, NIS2 or DORA evidence, full history exportable in an open format, a self-hosted or open-source edition with feature parity stated, and the vendor's own availability over several years published.
The Agency Developer
The reporting dashboard gives response times, success ratios and trends with P50, P95 and P99 percentiles, date ranges up to a custom window, saved views, a group-by-location breakdown, comparison of up to twelve checks, CSV export, and an Analytics API returning raw or aggregated series for automated periodic pulls. Retention is stated per plan — raw results up to 180 days and aggregated data up to 25 months on Enterprise — and the 90-day uptime formula with its outage weights is published for each component. We found no public information on SLA reports, scheduled email reports, published probe IP addresses for allow-listing, or the vendor's own public status page and incident history; the terms promise only commercially reasonable efforts toward availability. 8 9 13 20 21
The SaaS Platform Engineer
The reporting dashboard gives avg, P95 and P99 per check with filters and saved views, CSV export, and an Analytics API returning raw or aggregated data grouped by location and time window; TCP runs record DNS, connect and data phases separately, and retention is stated per plan — raw from 7 to 180 days, aggregated up to 25 months. The terms commit only to commercially reasonable efforts for availability, and we found no public information on the vendor's own public status page and incident history, published probe IPs, or an SLA with credits. 8 9 12 13 20 21
The Customer Support Lead
The reporting side is solid for a renewal conversation: a dashboard with response times, success ratios and P50, P95 and P99 percentiles, phase-level timings, saved views, retention stated per plan (raw 7 to 180 days, aggregated up to 25 months), CSV export and an Analytics and Reporting API returning raw and aggregated data points. What I cannot show a customer is the vendor's own record — we found no public information on Checkly's own status page or incident history, an SLA with credits (the terms promise only commercially reasonable efforts), or the probe IP addresses for allow-listing. 8 12 13 20 21
The E-Commerce Operations Manager
The reporting dashboard with average, P95 and P99 response times, per-phase timings, saved views, CSV export and an Analytics API, plus retention stated per plan (raw 7 to 180 days, aggregated up to 25 months), gives me the raw numbers for the agency conversation. But I found no scheduled email reports, no SLA with credits — the terms promise only commercially reasonable efforts to maintain availability — and nothing on the vendor's own status page, incident history or published probe addresses. 8 9 16 20 21
The Information Security Officer
The record itself holds up: P50/P95/P99 with DNS, connect and data timings captured per run and per location, CSV export, a reporting dashboard and an analytics API, retention stated per plan up to 180 days raw and 25 months aggregated, and the uptime calculation method published with its weights. The weaker half is the vendor's own trustworthiness: I found no public status page or incident history for Checkly itself, the availability commitment in the terms reads "commercially reasonable efforts" rather than an SLA with credits, and the probe IP addresses I would need for allow-listing are not published. 8 9 13 16 20 21
The Skeptic
The record itself is deep: P50/P95/P99 percentiles, per-phase latency, retention stated per plan from 7 days raw and 30 days aggregated on the free plan up to 180 days raw and 25 months aggregated on Enterprise, CSV export and an Analytics API returning raw or aggregated data — and the terms say plainly that content may be deleted at termination, so export before you leave. What I cannot find is the vendor's own heartbeat: we found no public information on their own status page, incident history, post-mortems or published probe IP addresses for allow-listing, and the terms commit only to "commercially reasonable efforts" while disclaiming any warranty that the service will be uninterrupted. 8 9 20 21
European sovereignty
panel opinion
Show reasoningHide reasoning
How this is scored
Who the contracting entity and the parent company are, where account data, alert contacts (names and phone numbers of the people on call), status page subscribers and check results are stored and processed, and who the subprocessors are (hosting, SMS and phone gateways, email delivery, support and payment tools). Independently sourced by the sovereignty pipeline. Probe locations outside Europe are part of what the product does and are not counted against it; where the data is stored and who processes it is. A self-hosted or open-source edition the customer runs on its own European servers counts as the customer's chain, whatever the vendor's seat.
0 — Non-EU vendor and contracting entity, hosting unstated, subprocessors unnamed, and no data processing agreement offered.
3 — A privacy policy and a data processing agreement exist, but hosting location is unstated or non-EU and the subprocessors are not listed.
5 — EU hosting available and an EU contracting entity or EU representative, but parts of the chain (SMS and call gateways, email, support, payment) run through non-EU providers without a stated safeguard.
8 — EU hosting on named infrastructure, EU contracting entity, subprocessors listed with their locations, a data processing agreement published, and security certifications (ISO 27001, SOC 2) stated — or a self-hosted edition documented that keeps every record on the customer's own servers.
10 — Sovereign end to end and evidenced: European ownership, entity, hosting and every subprocessor, or a self-hosted open-source edition with no call home, data export and deletion documented, and certifications published with their scope rather than implied.
The Agency Developer
The security page states all data is stored in the EU on AWS eu-west-1 in Ireland (check-result data may sit in the region where the check ran, with a disaster-recovery fallback to us-east-1), the terms incorporate a data processing addendum covering the EEA, subprocessors are listed by name — Auth0, AWS for email and SMS, Google, Stripe, Segment, Mixpanel, Clay, Knock, Loops, Anthropic and OpenAI — and Checkly itself is SOC 2 Type 2. But the contracting party is Checkly Inc. of Boston under New York law, and most of those subprocessors are US providers whose locations and safeguards are not stated beyond OpenAI's no-personal-data note. We found no public information on an EU contracting entity or representative, a self-hosted edition, or ISO 27001 for Checkly itself — for an agency with European clients that is the gap I weigh most. 9 10 11
The SaaS Platform Engineer
The security page states all data is stored in AWS eu-west-1 (Ireland), with only check result data possibly stored in the region where the check ran, a data processing addendum is incorporated into the terms, SOC 2 Type 2 is stated, and the privacy policy names the subprocessors — Auth0, AWS for email and SMS alerts, Stripe, Google, OpenAI, Anthropic, Mixpanel, Segment and others — though with their purposes rather than their locations. The contracting party is Checkly Inc. of Boston under New York law; a German affiliate is named without a stated role, and the documented disaster recovery fallback region is us-east-1. 9 10 11
The Customer Support Lead
The contracting party is Checkly Inc. of Boston under New York law, though a German affiliate is named; the security page states all data is stored in AWS eu-west-1 (Ireland), except that check result data may sit in the region where the check ran and disaster recovery falls back to us-east-1, and the privacy policy says processing may take place in the United States. Subprocessors are listed by name — AWS, Auth0, Stripe, Google, Segment, Mixpanel, OpenAI, Anthropic, Clay, Knock, Loops — but mostly without locations, and a data processing addendum plus SOC 2 Type 2 are published; we found no public information on an EU contracting entity or EU representative. 9 10 11
The E-Commerce Operations Manager
The security page states that all data is stored in AWS eu-west-1 (Ireland), a data processing addendum is incorporated into the terms, and Checkly holds SOC 2 Type 2 — reassuring for my subscribers' emails and my on-call staff's phone numbers. But I would contract with Checkly Inc. of Boston under New York law, the disaster-recovery fallback region is us-east-1, and the subprocessor chain runs through US providers such as Auth0, Stripe, Google, Segment and Anthropic with locations and safeguards largely unstated. 9 10 11
The Information Security Officer
The contracting party is Checkly Inc. of Boston under New York law, and the privacy policy states activities may take place in the United States; the captured pages give different indications on where data sits, with the security page stating all data is stored in AWS eu-west-1 (Ireland) and the terms incorporating a data processing addendum for EEA customers. Subprocessors are named — Auth0 holds the passwords, Google handles email, Stripe the payments, AWS the SMS and email alerts, plus Anthropic and Clay enriching signup data — but their locations are mostly unstated, the disaster-recovery fallback is the us-east-1 region, and SOC 2 Type 2 is the only certification stated for Checkly itself, with ISO 27001 claimed only for AWS and Auth0. 9 10 11
The Skeptic
The data sits on named EU infrastructure — AWS eu-west-1 in Ireland — with a data processing addendum incorporated into the terms, SOC 2 Type 2, and subprocessors named from Auth0 and AWS to Stripe, Google, Mixpanel and OpenAI. But the contract is with Checkly Inc. of Boston under New York law, the privacy policy says activities "may take place in the United States", and the disaster-recovery region is AWS us-east-1. We found no public information on where those subprocessors are located or where the German affiliate is seated — European storage with an American chain of command. 9 10 11
Pricing transparency
Show reasoningHide reasoning
How this is scored
Whether a buyer can compute the real annual cost from public pages alone: price per tier by number of monitors, check interval and status pages, team seats and on-call responders, what SMS and phone alerts cost, which features (multi-step or browser checks, SSO, longer retention, private locations, white-label) cost extra, the free tier and its limits, overage handling, minimum term and VAT.
0 — No public prices at all; every customer is a sales call.
3 — A starting price or a free tier exists, but how cost scales with monitors, intervals, seats or alerts is unclear.
5 — Tiers are public with their monitor count, interval and main inclusions, but at least one commonly needed piece (SMS or call alerts, extra seats, extra status pages, SSO, longer retention) is unpriced or "on request".
8 — Every tier priced publicly with its scaling rule (monitors, interval, seats, responders, status pages), SMS and call costs stated, add-ons priced, overage handling stated, minimum term and VAT treatment stated.
10 — Complete price computability: annual cost derivable for a given number of monitors, interval, team size and alert volume, with every add-on, overage and support fee and the cancellation and data-return terms published.
The Agency Developer
Every self-serve tier is public with its scaling rule: Hobby free and hard-capped at ten monitors, Starter $24 per month and Team $64 per month billed annually with 50 and 75 monitors, additional monitors in blocks of 25 at $8, billed per monitor rather than per run so a 30-second schedule costs the same as a daily one, and browser and API run overages priced per plan alongside SMS and phone alert quotas. Status pages are priced as Communicate add-ons at $9 and $30 per month with subscriber limits and overage billing, annual billing saves up to 20%, German invoices include VAT, upgrades are prorated and existing rates are grandfathered. We found no public information on extra user seats beyond the plan counts or the price of the Enterprise support tiers — the published block pricing is enough to plan a year at two hundred monitors. 5 8 13 17
The SaaS Platform Engineer
Hobby $0, Starter $24 per month and Team $64 per month billed annually are public with monitor counts (10, 50, 75, extra blocks of 25 at $8), users per plan, run quotas and overage rates — $2.60 per 10k API and $6.50 per 1k browser runs on Starter — plus priced Communicate ($9 and $30 per month) and Resolve ($12 and $39 per month) add-ons, subscriber overages explained, upgrades prorated and German invoices stated to include VAT. SMS and phone alerts are quoted as included monthly quotas, Enterprise is a custom quote, and we found no public information on a minimum term or per-message costs beyond the included quotas. 8 9 13 17
The Customer Support Lead
I could nearly compute our annual cost from the pricing pages alone: Hobby at $0 with hard caps, Starter at $24 per month billed annually and Team at $64 per month with monitor counts, users, locations and SMS and phone quotas, extra monitors at $8 per 25, run overages priced per thousand, the Communicate and Resolve add-ons priced separately, up to 20% annual discount, startup and nonprofit discounts, proration rules, and German invoices stated to include VAT. Enterprise is a custom quote, and we found no public price for additional user seats or SMS messages beyond the monthly quota, which keeps a full computation just out of reach. 8 9
The E-Commerce Operations Manager
I can nearly compute the season's cost from the pricing page alone: Starter $24 per month or Team $64 per month billed annually, additional 25 monitors for $8, browser overages at $6.50 or $6.25 per 1k runs, status-page modules at $9 and $30 per month, subscriber overages billed automatically, and German invoices including VAT. The gaps: no price for seats above the plan's user count, nothing on what SMS or calls beyond the monthly quota cost, add-ons like traces priced only through sales, and Enterprise is quote-only. 8 9 17
The Information Security Officer
Pricing is public to an unusual degree: Detect, Communicate and Resolve modules priced separately (Starter $24, $9 and $12 per month billed annually; Team $64, $30 and $39), monitors in blocks of 25 at $8, API and browser run overages priced per plan, SMS and phone alert quotas per tier, subscriber overages auto-billed, VAT treatment stated for German customers, and an annual discount of up to 20 percent. What I cannot compute from public pages: the Enterprise plan is a custom quote, the price of seats beyond each plan's included users is not stated, and I found no explicit minimum term. 5 8 9 17
The Skeptic
Almost everything a buyer needs to compute a bill is on the pricing page: tier prices, monitor counts with extra monitors at $8 per 25, overages such as $2.60 per 10k additional API runs and $6.50 per 1k browser runs on Starter, SMS and phone quotas per plan, retention per plan, up to 20% annual discount, 30% startup and 50% nonprofit discounts, prorated upgrades, and overages billed to the next invoice. VAT is stated for German customers and fees are exclusive of taxes. We found no public information on per-seat pricing beyond the included users or on the price of Enterprise add-ons and support tiers, and the only data-return term is that content may be deleted at termination. 8 9 13 17
European sovereignty — proven facts
1 of 6 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Incorporated in US ⚠ unverified | 0/2 pts | 9 Report an error |
|---|---|---|---|
| Hosting location | Not determined ⚠ unverified | — | uncited Report an error |
| Hosting options | Not determined ⚠ unverified | — | uncited Report an error |
| Open source | Not determined | — | uncited Report an error |
| Data processing agreement | Not determined ⚠ unverified | — | uncited Report an error |
| Transfer impact assessment | Not determined | — | uncited Report an error |
Questions about Checkly
Is Checkly European?
No. whats-best.ai classifies Checkly as Rest of world. Its vendor, Checkly Inc., is incorporated in United States, per the vendor’s page captured 1 Nov 2026.
Where does Checkly store data?
Not stated on the vendor’s pages as of 1 Nov 2026.
Does Checkly have a free plan?
Not stated on the vendor’s pages as of 1 Nov 2026.
What are the best alternatives to Checkly?
As of 2 Nov 2026, the panel rates Hyperping (3.5/5), openstatus (3.5/5) and Oh Dear (3.5/5) highest among the other 14 Uptime Monitoring & Status Pages products evaluated. Ratings that look equal are rounded to half stars; the order uses the unrounded rating, then the name. The highest-rated European alternative is Hyperping (EU-Made). Ratings are the AI panel’s opinion, formed from public evidence: how scores are made. The full list, with European products first: Checkly alternatives.
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 1 Nov 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- Weak sourcing — Data processing agreement, Hosting location, Hosting options. Not confirmed on the vendor’s own pages as captured.
- Weak sourcing — Legal entity. The terms name a principal place of business rather than a register of incorporation; a German affiliate (Checkly GmbH) is mentioned but its seat is not stated.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- 19 product facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 17 integrations facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 1 pricing fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
- 3 sovereignty dimensions could not be confirmed on the vendor’s own pages and are shown as unknown. Know more? Tell us
Sources (21)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor homepage www.checklyhq.com Checked 1 Nov 2026 Details →
- 2 Features page (API monitoring) www.checklyhq.com Checked 1 Nov 2026 Details →
- 3 Features page (browser and synthetic monitoring) www.checklyhq.com Checked 1 Nov 2026 Details →
- 4 Features page (heartbeat monitoring) www.checklyhq.com Checked 1 Nov 2026 Details →
- 5 Features page (status pages) www.checklyhq.com Checked 1 Nov 2026 Details →
- 6 Features page (alerting) www.checklyhq.com Checked 1 Nov 2026 Details →
- 7 Documentation www.checklyhq.com Checked 1 Nov 2026 Details →
- 8 Pricing page www.checklyhq.com Checked 1 Nov 2026 Details →
- 9 Terms of service www.checklyhq.com Checked 1 Nov 2026 Details →
- 10 Privacy policy www.checklyhq.com Checked 1 Nov 2026 Details →
- 11 Security / trust page www.checklyhq.com Checked 1 Nov 2026 Details →
- 12 Checks, locations & failure confirmation — found from sitemap www.checklyhq.com Checked 1 Nov 2026 Details →
- 13 Checks, locations & failure confirmation — found from sitemap www.checklyhq.com Checked 1 Nov 2026 Details →
- 14 Alerting, escalation & on-call — found from sitemap www.checklyhq.com Checked 1 Nov 2026 Details →
- 15 Alerting, escalation & on-call — found from sitemap www.checklyhq.com Checked 1 Nov 2026 Details →
- 16 Status pages & incident communication — found from sitemap www.checklyhq.com Checked 1 Nov 2026 Details →
- 17 Status pages & incident communication — found from sitemap www.checklyhq.com Checked 1 Nov 2026 Details →
- 18 API, monitoring as code & team administration — found from sitemap www.checklyhq.com Checked 1 Nov 2026 Details →
- 19 API, monitoring as code & team administration — found from sitemap www.checklyhq.com Checked 1 Nov 2026 Details →
- 20 Uptime reports, data & the vendor's own reliability — found from sitemap www.checklyhq.com Checked 1 Nov 2026 Details →
- 21 Uptime reports, data & the vendor's own reliability — found from sitemap www.checklyhq.com Checked 1 Nov 2026 Details →