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. Passing checks can expose assertion details, and failed checks link to a full check details page.
Check Details
Check details include timing, region-level results, assertions, errors, and execution details. For HTTP checks, request and response details can be inspected. For ping and port checks, traceroute data may be available from the execution.
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.