# Availability Measurement Methodology

**Source**: https://www.checklyhq.com/availability/methodology/

> Every 10 minutes, Checkly sends a real request from N. Virginia and Frankfurt to a published endpoint for each service and records the response status, response time, and timing breakdown. The result measures that probe—not every feature or region of the provider.

## Measure the service, not complaints

Each result comes from a scheduled synthetic check. It is not inferred from social posts, support tickets, or user reports. Where possible, the target is the API, registry, or application endpoint developers actually depend on rather than a marketing homepage.

## Published probe targets

Every service page discloses the exact URL being checked and explains why that endpoint was selected when the choice is not obvious. This makes the measurement reproducible and exposes the scope of the claim.

## How to read a result

- A successful response means the published endpoint answered the configured request.
- A failed response means the check could not complete successfully after its configured retry behavior.
- Response time and phase timings describe the measured request from the listed Checkly locations.
- A passing probe does not prove every feature, account, or provider region is healthy.
- A regional or feature-specific incident can exist while the public probe remains healthy.

The availability pages are informational and are not the service provider's official status page. Confirm incidents against the provider's own status page and telemetry from your application.

## Related resources

- [Live service availability](https://www.checklyhq.com/availability/)
- [Uptime Monitoring](https://www.checklyhq.com/product/uptime-monitoring/)
- [Checkly locations](https://www.checklyhq.com/docs/concepts/locations/)