Checks
A check is one execution of a runner-based monitor. HTTP, ping, port, and custom monitors create checks on their schedules. Heartbeat monitors receive pings instead of scheduled checks.
Monitor Detail Tabs
Monitor detail pages include tabs for incidents, activity, checks or pings, and comments. Heartbeat monitors show a Pings tab; other monitor types show a Checks tab.
Check History
The Checks tab shows timestamp, outcome, and error. Every row links to its check details page. When assertion data is present, the outcome control also opens the assertions directly.
Check Details
Check details show the check time, current outcome, participating regions, assertions, captured metric values, and any error. When a backing execution exists, Show Execution Details opens the scenario or protocol execution results.
Assertions and Success Criteria
Assertions and success criteria determine whether a check passes. Success criteria can use default organization settings, monitor-type settings, custom scenario-type settings, or monitor-specific overrides.
Region-Based Results
Monitors with multiple runner regions produce region-level check results. This helps distinguish a global outage from a regional network, DNS, or runner-specific issue.
Heartbeat Pings
Heartbeat monitors do not create scheduled checks. Their Pings tab lists recent POSTs with timestamp, source, and optional data. Ping data can be opened in a JSON viewer when the payload is large.
On-Demand Runs
Runner-based monitors can be run outside their normal schedule from monitor actions when supported. This is useful after edits or while validating a fix.
Best Practices
- Use check history to confirm whether a failure is isolated or repeated.
- Compare region results before assuming the monitored service is globally down.
- Inspect assertions first for expected-condition failures, then request/error details for transport failures.
- Use comments on monitors or incidents to preserve investigation context.