Create and manage HTTP checks programmatically. Same checks, same alerting and same incident history as the ones you would create by hand — just addressable from your own code.
Free plan forever · No credit card · Set up in under a minute
An uptime monitor asks a URL whether it is still answering, on an interval you choose, and raises an incident when it stops. Through the API you can create one per customer, per environment or per deploy, and tear it down again when it is no longer needed.
Post the address to watch, how often to check it, and what counts as a failure.
curl -X POST https://monitoringdaddy.com/api/v1/monitors \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Checkout API",
"url": "https://example.com/health",
"type": "uptime",
"interval": 300,
"request_method": "GET",
"alert_condition": "url_unavailable"
}'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 |
|---|---|---|
name |
string | Required. What you will recognise it by. Unique within your account. |
url |
string | Required. The address to check. |
type |
string | uptime. Also accepts ssl, domain and api. |
interval |
integer | Seconds between checks. Your plan decides which values are allowed. |
request_method |
string | GET, POST, HEAD and the rest. |
alert_condition |
string | url_unavailable, or a keyword condition paired with alert_text_lookup. |
alert_text_lookup |
string | The text to look for, when the condition needs one. |
request_headers |
array | Objects of {key, value}, for authenticated endpoints. |
request_auth_username |
string | HTTP Basic user. The matching password can be set but never read back. |
alerts |
array | Where to send alerts: objects of {key, value}, one per channel. |
GET | /api/v1/monitors?kind=uptime | 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 |
One endpoint returns every kind of check on the account, so narrow it with kind=uptime.
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.
That is a plan setting rather than an API one — the interval you send is validated against the intervals your plan allows, and refused with a 422 if it is faster.
Identically. Alert channels are per monitor, set through the alerts field, and incidents are raised by the same checker that handles monitors made in the interface.
Yes — request_headers carries bearer tokens or API keys, and request_auth_username with its password covers HTTP Basic.
The create call returns 422 with a message saying the allowance is used up. Nothing is created and nothing is charged.
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.