Interval-based alerting
Tell us how often the job should ping, from every 60 seconds up. If the newest ping is older than that interval when the check is evaluated, the check fails and your notification groups are alerted.
Cron Job Monitoring
Know the second
Know the second
a job goes silent.
Heartbeat & dead-man's-switch monitoring for scheduled work: cron jobs, backups, ETL pipelines and queue workers. Each job gets a unique ping URL and calls it when a run finishes. If the pings stop, your team is alerted.
Free tier included
No credit card
2-minute setup
nightly-backup HealthyLIVE
LAST PING02:01 UTC
INTERVAL24h
LAST CHECKED02:30 UTC
Monping
Tueping
Wedping
Thuping
Friping
Monitoring for the jobs that never make a request.
Uptime checks work by making HTTP requests. Scheduled jobs work the other way round. They call home when they succeed. Site Qwality gives each job a unique ping URL; silence means something went wrong.
Slightly late is not a page
Each check is evaluated once per interval, so a missed ping is caught between one and two intervals after the last good one, and a run a few minutes late usually does not alert. Configurable grace periods are on the roadmap.
Every ping recorded
Each ping is stored with its time, source address and request headers, so you can see which host or runner called in. Read the receipts back through the API.
Alerts and incidents
Failures and recoveries go to the notification groups you choose. Link a check to a service and it can open an incident automatically and resolve it when pings resume.
One-line integration for any stack
A plain HTTPS request to your ping URL, with no SDK and no agent. Works from bash, Python, Node, Ruby, Go, or anywhere else you can make a request.
Failure history and uptime
Every failure window is recorded, and an uptime percentage is available per check through the API. A heartbeat component on a status page follows the check.
Dead-man's switch pattern
No ping means
No ping means
something broke.
Traditional monitoring checks that your service responds. Cron monitoring inverts that: your job reports each successful run, and a missing report is itself the alert. There's no polling, no log scraping, no agent to maintain.
- Each check gets a unique ping URL your job calls when a run finishes
- A ping older than the interval fails the check at its next evaluation
- The next ping flips it back to healthy and closes the failure window
daily-report-etl FailedLIVE
EXPECTEDevery 24h
LAST PINGyesterday 06:00
STATUSFailed
Monping
Tueping
Wedping
Thuping
Frino ping
One-line integration
Add a ping.
Add a ping.
That's the whole job.
No SDK, no daemon, no config file. Copy the ping URL from your dashboard and append a curl call to your existing script, after the work has succeeded.
- Works from any language or shell that can make an HTTP request
- Any HTTP method is accepted, and POST is the convention
- Send a custom header such as the hostname to see which runner pinged
wrap any script#!/bin/bash
set -euo pipefail
# your job
python /opt/etl/run.py
# ping Site Qwality, only reached on success
curl -fsS -X POST "https://ping.siteqwality.com/<account-id>/<cron-job-id>"
✓ ping received · recorded
set -euo pipefail
# your job
python /opt/etl/run.py
# ping Site Qwality, only reached on success
curl -fsS -X POST "https://ping.siteqwality.com/<account-id>/<cron-job-id>"
✓ ping received · recorded
1
line of code to integrate any scheduled job
60s
shortest expected interval between pings
25
cron monitors on the free tier
$0
free tier, no credit card needed to start
FAQ
Each monitor gets a unique ping URL. Your job calls it when a run finishes successfully. Site Qwality compares the newest ping with the interval you set, and if the ping is older than that, or none has ever arrived, the check fails and your notification groups are alerted.
Set the interval to the time between scheduled runs, not the run time, and ping at the end of the job. A check is evaluated once per interval, so a run that is a few minutes late usually does not alert. There is no separate grace period setting or maximum-duration alert today. For a hard runtime ceiling, emit a duration metric and alert on that.
Not today. A cron check records that a ping arrived, with its time, source address and headers. It does not read an exit code or a duration. To tell success from failure, ping only after the job succeeds, or use a second check for failures, and send a metric for finer detail.
No. The integration is a single HTTPS request: a curl command, a fetch() call, or the equivalent in any language. No daemon, no agent, no code dependency to maintain.
Yes. The interval is at least 60 seconds and a multiple of 60. You set the interval between pings, for example 86400 for a daily job, rather than a cron expression. Detection takes one to two intervals, so a daily job alerts between 24 and 48 hours after its last ping and a 5-minute job after 5 to 10 minutes of silence.
The cron job monitoring tools guide compares nine tools from their own pricing and documentation pages, including the cases where Healthchecks.io or Cronitor is the better pick.
Related features
Kostenlos starten. Keine Kreditkarte.
Uptime, Cron, Synthetic, Logs, RUM, Incidents und Statusseiten. Kostenlose Stufe bei jedem Produkt.