A job that fails loudly gets noticed. A job that silently stops running does not — because a run that never happened produces no error at all. This watches for the absence.
Free plan forever · No credit card · Set up in under a minute
Create a heartbeat and we mint a ping URL. Your job calls it on success; if a call does not arrive within the period plus its grace, we alert you. Nothing is fetched from your side, so it works for jobs on machines we could never reach.
A heartbeat needs no address and no interval of its own — set heartbeat to 1 and give it a period. The ping URL comes back in the response.
curl -X POST https://monitoringdaddy.com/api/v1/monitors \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Nightly database backup",
"heartbeat": 1,
"heartbeat_period": 86400,
"heartbeat_grace": 3600
}'Send your key as a bearer token. You will find it under Account → API, and it identifies the account everything is created against.
A successful create returns 201 with the whole resource, including its id — keep that if you intend to update or delete it later.
| Field | Type | What it does |
|---|---|---|
heartbeat |
integer | Required, set to 1. This is what makes the resource a cron job monitor. |
heartbeat_period |
integer | How often the job is expected to call in, in seconds. From five minutes to a week. |
heartbeat_grace |
integer | How late it may be before we treat the run as missed. Between 60 and 86,400 seconds. |
name |
string | Required. Unique within your account. |
alerts |
array | Where to send the alert. A job usually fails overnight, which is the worst time for one address. |
GET | /api/v1/monitors?kind=heartbeat | List these |
POST | /api/v1/monitors | Create one |
GET | /api/v1/monitors/{id} | Fetch one |
PUT | /api/v1/monitors/{id} | Update one |
DELETE | /api/v1/monitors/{id} | Delete one |
GET | /api/v1/incidents | Incidents across the account |
Narrow the list with kind=heartbeat.
The create response carries url — that is the ping address. Call it at the end of a successful run. Any method works and nothing needs to be sent in the body.
Nothing extra. Anything you create through the API counts against the same plan allowance as anything you create in the interface — the same monitors, watches and cron jobs, in the same pool. There is no per-call charge, no separate API tier and no credits to top up. If your plan allows fifty monitors, you may have fifty, however you made them.
The API is the whole product, not a subset of it. Everything the interface can create, the API can create, and both write to the same account — so you can run your own front end, resell monitoring under your own name, or wire checks into a product you already sell, and still log in here to see the same data. Alerts, incidents and status pages all behave identically whichever way the resource was made.
Only call the ping URL on success. A job that exits with an error and skips the ping is reported as missed, which is what you want.
That is what grace is for. The alert fires when the period plus the grace has passed with no call, so an occasional slow run is tolerated.
Yes. The call goes outward from your machine to us, so nothing needs to be reachable from outside.
No. Cron jobs have their own allowance on your plan, separate from monitors and page watches.
Uptime, SSL, domain expiry, page changes and cron jobs, all from one REST API. Free plan, no card, and API access on every paid plan.