Active Monitoring
Active monitoring lets CronBeat proactively check your endpoints on a schedule. Unlike heartbeat monitoring where your jobs ping CronBeat, active monitors work the other way around — CronBeat reaches out to your services to verify they're healthy.
How It Works
- You create a monitor and specify what to check (URL, host, port)
- CronBeat checks the target at the configured interval
- If the check fails or an alert rule matches, CronBeat triggers an alert
- When the issue resolves, CronBeat sends a recovery notification
No code changes needed on your end — just tell CronBeat what to monitor.
Monitor Types
HTTP Monitoring
Monitor any HTTP/HTTPS endpoint. CronBeat sends a request and validates the response.
Configuration options:
| Field | Required | Description |
|---|---|---|
| URL | Yes | The full URL to check (e.g., https://api.example.com/health) |
| Method | No | HTTP method: GET (default), POST, PUT, PATCH, DELETE, HEAD |
| Headers | No | Custom request headers (up to 20) |
| Cookies | No | Custom cookies to send (up to 20) |
| Body | No | Request body for POST/PUT/PATCH (up to 10KB) |
| Follow Redirects | No | Follow HTTP redirects (default: yes) |
| Validate SSL | No | Verify SSL certificate validity (default: yes) |
What CronBeat checks:
- Connection success (DNS resolution, TCP handshake, TLS negotiation)
- HTTP response received within timeout (10 seconds)
- Alert rules you configure (status code, response time, body content)
Example use cases:
- Health check endpoints (
/health,/status) - API availability (
GET /api/v1/users) - Website uptime (
GET https://example.com) - Webhook receivers (
POST /webhooks/test)
TCP Monitoring
Verify that a TCP port is accepting connections. Useful for databases, message queues, and other TCP services.
Configuration options:
| Field | Required | Description |
|---|---|---|
| Host | Yes | Hostname or IP address |
| Port | Yes | TCP port number |
What CronBeat checks:
- TCP connection can be established within timeout (10 seconds)
Example use cases:
- Database servers (PostgreSQL on port 5432, MySQL on 3306)
- Redis / Memcached (port 6379 / 11211)
- Message queues (RabbitMQ on 5672, Kafka on 9092)
- Custom TCP services
ICMP Ping Monitoring
Check if a host is reachable via ICMP ping. The most basic connectivity check.
Configuration options:
| Field | Required | Description |
|---|---|---|
| Host | Yes | Hostname or IP address |
What CronBeat checks:
- Host responds to ICMP echo request within timeout (5 seconds)
Example use cases:
- Server availability
- Network connectivity
- VPN gateway reachability
Check Intervals
Choose how often CronBeat checks your endpoints:
| Interval | Availability |
|---|---|
| Every 1 minute | Paid plans only (Starter and above) |
| Every 5 minutes | All plans |
| Every 10 minutes | All plans |
| Every 30 minutes | All plans |
| Every 1 hour | All plans |
Shorter intervals catch issues faster but consume more of your monitor quota. Choose based on how critical the service is.
Alert Rules
Alert rules let you define custom conditions that trigger alerts, beyond simple up/down detection. Add multiple rules to a single monitor — if any rule matches, an alert is triggered.
Response Time
Alert when response time exceeds a threshold:
| Rule | Description | Available For |
|---|---|---|
| Response time > N ms | Triggers when response takes longer than N milliseconds | HTTP, TCP, Ping |
Example: Alert if your API takes longer than 3000ms to respond.
HTTP Status Code
Alert when the response status code is not in the expected categories:
| Rule | Description | Available For |
|---|---|---|
| Status code not in [categories] | Triggers when status code falls outside selected categories (2xx, 3xx, 4xx, 5xx) | HTTP only |
Example: Alert if the status code is not 2xx (i.e., any non-success response).
Response Body Content
Alert based on the response body:
| Rule | Description | Available For |
|---|---|---|
| Body contains | Triggers when body includes the specified text | HTTP only |
| Body not contains | Triggers when body does NOT include the specified text | HTTP only |
Example: Alert if the body does not contain "status":"ok", or alert if the body contains "error".
Combine multiple rules for comprehensive monitoring. For example: status code must be 2xx AND response time must be under 5000ms AND body must contain "healthy".
Check Results
Each check records:
- Status: Success or failure
- Response time: How long the check took (in milliseconds)
- Error details: If the check failed, what went wrong
Common error types for failed checks:
| Error | Description |
|---|---|
| TIMEOUT | Check did not complete within the timeout period |
| DNS_RESOLUTION_FAILED | Could not resolve the hostname |
| CONNECTION_REFUSED | Target actively refused the connection |
| CONNECTION_RESET | Connection was reset during the check |
| SSL_ERROR | TLS/SSL handshake or certificate error |
| NETWORK_ERROR | General network connectivity issue |
| HOST_UNREACHABLE | Target host is not reachable |
Best Practices
- Use dedicated health endpoints — Don't monitor your homepage; create a
/healthendpoint that checks dependencies - Set appropriate intervals — Critical services: 1-5 min. Less critical: 10-30 min
- Combine with alert rules — A 200 OK doesn't always mean healthy; validate response content too
- Monitor from the user's perspective — Check public URLs, not internal addresses
- Enable SSL validation — Catch certificate issues before they affect users