Types of Checks
Checkly’s flexible offering includes several types of Checks, each designed for different levels of complexity and testing scenarios:URL Monitors
URL Monitors
Monitor HTTP/HTTPS endpoints for availability and basic performance. URL Monitors check if your websites and APIs are responding correctly by making HTTP requests and validating the response.Perfect for:
- Website uptime monitoring
- API endpoint availability
- Basic performance tracking
- SSL certificate monitoring
TCP Monitors
TCP Monitors
Verify connectivity to any TCP service by establishing connections to specific hosts and ports. TCP Monitors test the availability of non-HTTP services and infrastructure components.Perfect for:
- Database connectivity
- Custom application services
- Network service availability
- Port accessibility testing
Heartbeat Monitors
Heartbeat Monitors
Monitor scheduled processes, cron jobs, and batch operations that should “check in” at regular intervals. Instead of actively testing your service, Heartbeat Monitors wait to receive a signal from your system.Perfect for:
- Backup job verification
- Scheduled task monitoring
- Batch process oversight
- Data pipeline health
API Checks
API Checks
Advanced API testing that goes beyond basic uptime monitoring. Use setup and teardown scripts, complex assertions, and custom request handling. Validate that your backend services respond correctly, perform within acceptable timeframes, and return the right data structures.Perfect for:
- Complex API endpoint validation
- Authentication and authorization testing
- Data structure and schema validation
- Performance benchmarking
- Custom request/response handling
- Integration testing between services
Multistep Checks
Multistep Checks
Write sophisticated Node.js scripts that run multiple API requests in sequence with arbitrary code between requests. Perfect for testing complex workflows involving authentication, data manipulation, and multi-step processes that span multiple endpoints.Perfect for:
- Multi-step authentication flows
- Data transformation workflows
- Complex business logic testing
- End-to-end API integrations
- Workflow orchestration testing
- Cross-service data validation
Browser Checks
Browser Checks
Simulate real user interactions in a headless browser using TypeScript/JavaScript with @playwright/test. Navigate, screenshot, and assert your key webapp flows. Browser Checks can handle complex scenarios that simple uptime monitoring cannot.Perfect for:
- Complete user journey testing
- Login flows and authentication
- Checkout processes and e-commerce flows
- Form submissions and data entry
- Visual regression testing
- Mobile device emulation
Playwright Checks
Playwright Checks
Run entire Playwright test suites and projects as production monitors without code rewrites. Playwright Check Suites support the full Playwright API and ecosystem, enabling you to use existing tests and configuration files as-is.Perfect for:
- Converting existing E2E tests into monitoring
- Testing complex user workflows across multiple browsers
- Monitoring critical business processes
- Validating application functionality after deployments
How Checks Execute
- A cron process picks up a check based on its schedule, say every 5 minutes. It validates that the check is not in progress at the moment to avoid race conditions. The check is put into a queue to be run from the next configured data center location.
- If the check is an API check and has a setup script, the setup script is executed.
- The check is executed.
- If the check is an API check and has a teardown script, the teardown script is executed. Teardown scripts are run before any assertions are validated.
- The result is stored in our central database.
- If the check fails, its retry strategy is executed. Based on the retry strategy, a check is retried one or multiple times. Any setup & teardown scripts are run again as part of the process.
- Alerts are sent out in requested channels when the sequence is complete. It’s considered complete when the check run was successful or the final attempt was executed. We will send alerts only if the final attempt has failed (no alerts sent for the initial attempts)