Backups, imports, exports, billing runs, queue workers — anything that is supposed to happen on a schedule and would go unnoticed for days if it stopped.
Free plan forever · No credit card · Set up in under a minute
The mechanism is the same as cron job monitoring: we issue a ping URL, your task calls it when it finishes, and we alert when a call fails to arrive. What differs is the shape of the work — longer periods, longer grace, and often one monitor per tenant or per pipeline stage, which is exactly the sort of thing worth creating from code rather than by hand.
Longer-running work usually wants a generous grace: an import that normally takes twenty minutes should not alert because it took forty.
curl -X POST https://monitoringdaddy.com/api/v1/monitors \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Weekly analytics rollup",
"heartbeat": 1,
"heartbeat_period": 604800,
"heartbeat_grace": 7200
}'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. |
heartbeat_period |
integer | Expected interval between check-ins, up to a week. |
heartbeat_grace |
integer | How much lateness to tolerate before alerting. |
name |
string | Required. Unique within your account. |
alerts |
array | Where to send the alert. |
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. Cron jobs and scheduled tasks share this kind.
For multi-stage work, create one monitor per stage and ping each as it completes. When something stops, the alert names the stage that stopped rather than the pipeline as a whole — which is the difference between knowing something is wrong and knowing what is wrong.
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.
It is the same mechanism, described for a different kind of work. Longer periods and longer grace, usually created per tenant or per stage.
Yes — have the worker ping on a timer rather than per job, so the check is about the worker still being alive rather than about throughput.
The period the job actually runs at, with grace covering how late it can acceptably be. A weekly job with two hours of grace alerts when it is more than two hours overdue.
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.