Overview
This endpoint provides real-time status information for all checks in your account. Check statuses give you an immediate overview of system health, availability, and performance trends without diving into detailed execution results.Response Example
Common Use Cases
System Health Dashboard
Incident Detection
Performance Monitoring
SLA Reporting
Query Parameters
Filtering Options
Filtering Options
status
(string): Filter by check status (passing, failing, degraded)checkType
(string): Filter by check type (api, browser, heartbeat, tcp, multistep)group
(string): Filter by check group IDtags
(array): Filter by tags (comma-separated)location
(string): Filter by monitoring locationhasIncident
(boolean): Filter checks with active incidents
Performance Filters
Performance Filters
availabilityMin
(number): Minimum availability percentage (0-100)availabilityMax
(number): Maximum availability percentage (0-100)responseTimeMin
(number): Minimum average response time (ms)responseTimeMax
(number): Maximum average response time (ms)trend
(string): Performance trend (improving, stable, degrading)
Pagination & Sorting
Pagination & Sorting
page
(integer): Page number (default: 1)limit
(integer): Number of items per page (default: 10, max: 100)sortBy
(string): Sort field (name, status, availability, responseTime, lastExecution)sortOrder
(string): Sort order (asc, desc, default: desc for timestamps)includeSummary
(boolean): Include account-wide summary statistics (default: true)
Status Types
Passing
- Recent executions successful
- Availability within acceptable range
- No active alerts or incidents
- Performance meeting SLA targets
- Last 3 executions successful
- Availability > 95% (24h)
- No active critical alerts
Failing
- Recent executions failed
- Service unavailable or unreachable
- Critical functionality broken
- Active incident likely
- Last 2+ executions failed
- Multiple location failures
- Active critical alerts
Degraded
- Intermittent failures
- Performance below targets
- Partial functionality available
- Requires monitoring
- Mixed success/failure results
- Availability 85-95% (24h)
- Response times above thresholds
Unknown
- Insufficient data to determine status
- Check recently created
- Execution suspended
- Configuration issues
- No recent execution data
- Check disabled or paused
- Location unavailable
Performance Trends
Trend Analysis
Trend Analysis
- Response times decreasing
- Availability increasing
- Error rates reducing
- Response times within ±10% of baseline
- Availability maintained
- No significant pattern changes
- Response times increasing
- Availability decreasing
- Error rates rising
Performance Thresholds
Performance Thresholds
- Excellent: < 200ms
- Good: 200-500ms
- Fair: 500-1000ms
- Poor: > 1000ms
- Excellent: ≥ 99.9%
- Good: 99.0-99.9%
- Fair: 95.0-99.0%
- Poor: < 95.0%
Use Cases
System Health Dashboard
System Health Dashboard
- Display overall system availability
- Highlight failing or degraded services
- Show performance trends at a glance
- Track SLA compliance across services
Incident Detection
Incident Detection
- Detect patterns indicating incidents
- Correlate failures across related checks
- Prioritize response based on severity
- Track incident resolution progress
Performance Monitoring
Performance Monitoring
- Monitor response time trends
- Identify degrading services
- Plan capacity based on performance data
- Set up predictive alerting
SLA Reporting
SLA Reporting
- Calculate uptime percentages
- Track SLA violations
- Generate executive summaries
- Export compliance data
Location-Specific Status
Understanding Location Status
Understanding Location Status
passing
: Recent executions successful from this locationfailing
: Recent executions failed from this locationdegraded
: Mixed results or performance issuesunknown
: No recent data or location unavailable
- Identify regional performance issues
- Plan infrastructure improvements
- Route traffic away from problematic regions
- Understand global service health
Regional Performance Analysis
Regional Performance Analysis
Real-Time Updates
Polling Strategy
Polling Strategy
- Critical systems: Poll every 30 seconds
- Standard monitoring: Poll every 2-5 minutes
- Executive dashboards: Poll every 5-10 minutes
Change Detection
Change Detection
Additional Examples
Authorizations
The Checkly Public API uses API keys to authenticate requests. You can get the API Key here.
Your API key is like a password: keep it secure!
Authentication to the API is performed using the Bearer auth method in the Authorization header and using the account ID.
For example, set Authorization header while using cURL:
curl -H "Authorization: Bearer [apiKey]" "X-Checkly-Account: [accountId]"
Headers
Your Checkly account ID, you can find it at https://app.checklyhq.com/settings/account/general
Response
Successful
The name of the check.
"API Check"
The ID of check this status belongs to.
"1008ca04-d3ca-41fa-b477-9e99b761dbb4"
Describes if this check is currently failing. If any of the assertions for an API checkfail this value is true. If a browser check fails for whatever reason, this is true.
false
Describes if due to some error outside of normal operation this check is failing. This should be extremely rare and only when there is an error in the Checkly backend.
false
A check is degraded if it is over the degradation limit set by the "degradedResponseTime" field on the check. Applies only to API checks.
true
The longest ever recorded response time for this check.
10
The shortest ever recorded response time for this check.
5
What location this check was last run at.
"us-east-1"
The unique incrementing ID for each check run.
"f10d711f-cd16-4303-91ce-741c92586b4a"
How many days remain till the current SSL certificate expires.
3