Point a check at a hostname and get told before its certificate expires — days ahead, not on the morning the browser starts refusing connections.
Free plan forever · No credit card · Set up in under a minute
An expired certificate is one of the few outages that is entirely predictable and still happens constantly. This creates a check that reads the certificate, records issuer and expiry, and alerts you a chosen number of days before it lapses.
Send the address and how much warning you want.
curl -X POST https://monitoringdaddy.com/api/v1/monitors \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "example.com certificate",
"url": "https://example.com",
"type": "ssl",
"interval": 3600,
"request_method": "GET",
"alert_condition": "url_unavailable",
"ssl_alert_days": 14
}'
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. Unique within your account. |
url |
string | Required. The https address whose certificate you want watched. |
type |
string | ssl. |
ssl_alert_days |
integer | How many days before expiry to warn you. Required for this type — a certificate check with no warning window would sit there checking nothing. |
interval |
integer | How often to re-read the certificate. |
alerts |
array | Where to send the warning. |
GET | /api/v1/monitors?kind=ssl | 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=ssl to get certificate checks only.
A certificate check carries ssl_ends_at, ssl_created_at and an ssl_information object with the issuer and subject, so you can render your own expiry dashboard without re-reading the certificate yourself.
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.
Anything from a day to a couple of months — the accepted values are the same ones the interface offers.
It reads the certificate the host presents, including issuer and validity dates, which is what determines whether a browser will accept it.
Include the port in the url and it will be used.
Yes — it comes out of the same monitor allowance as an uptime check.
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.