Website monitoring webhooks
Uptimia checks your sites, certificates and checkout flows from outside your network and calls your endpoint with every confirmed failure. Your own code decides what happens next — open a ticket, restart a service, feed a dashboard — and every check sends the same format, so you write the handler once.
Authorization: Bearer •••••••••••••••• Content-Type: application/json { "id": 3517, "monitor_type": "uptime", "monitor_name": "Checkout — caldmont.com", "monitor_unique_id": "checkout-prod", "monitor_status": "down", "severity": "critical", "incident_start_time": "2026-07-30T11:47:12+02:00", "incident_end_time": "", "incident_duration_seconds": 0, "message": "*ALERT*: Project Checkout — caldmont.com is DOWN", "monitor_notes": "Failover: drain eu-west-2 first" }
Not a message, a contract
Every other channel ends at a person, and people are forgiving readers. Code is not — which is why the interesting part is never the payload, but the guarantees behind it.
“Something broke” — you work out the rest
Wording can drift between releases because the reader adapts. The moment software depends on it, that informality becomes a fault in your integration.
Eleven fields, five retries, one shape
One object for every kind of check: write one handler, branch on two fields. It is retried five times before it drops, so duplicates are possible — documented rather than discovered.
The alert lands in your own code
A check fails and Uptimia calls your endpoint with the details, already confirmed. Your own automation decides what happens next — here, a ticket that opens itself and closes on recovery.
Connect a webhook in three steps
No app to authorise and no library to install — Uptimia needs a URL to call and, if the endpoint is protected, a header that gets it in.
Paste your endpoint’s URL
That is the whole registration — one public URL.
Add your auth headers
Optional — headers are sent exactly as you write them, so a token gets Uptimia through your own door.
Point your monitors at it
Pick the checks that should call it, and a test delivery proves the wiring with the real format.
Register a webhook endpoint
The Help Center covers the implementation: adding the URL, writing the custom headers, sending a test POST, and reading what a failed delivery is telling you.
Every kind of check. One shape.
An expiring certificate, a cron job that never checked in and a server over its CPU threshold all arrive as the same flat object. Two fields tell them apart.
Chat bridges, database rows, automated actions
Once an incident is an object your code has accepted, the useful applications stop looking like alerting.
Other channels tell a person.This one tells your code.
The whole platform on the trial — every kind of check, 171+ checkpoints, and every confirmed incident delivered as an object you own.
The delivery guarantees, written down
Nobody can write a dependable handler against “we will send you a notification”. These are the actual guarantees.
At-least-once, with five retries
Ten seconds to answer, and any 2xx counts as accepted. Anything else is re-queued and retried five times, each wait a minute longer than the last, then dropped — so answer first and do the work afterwards.
One flat object, eleven keys
No nesting, no envelope, no schema that changes with the check type. Two fields discriminate; the other nine never change meaning — including monitor_notes, the runbook line whoever set the monitor up left behind.
A storm adds a key
Monitors failing together become one request with an extra group object — members, counts, acknowledgement. Handlers that ignore it keep working.
Your headers, passed through
Sent verbatim, so a bearer token or shared secret works. There is no body signature — check the header server-side, and keep the URL secret.
Where it will refuse to post
Public http(s) only; loopback and private ranges are rejected. The address is resolved once and pinned, redirects ignored, TLS verified.
No acknowledge link — on purpose
Channels a person reads carry a signed link that stops the ladder. Machines get the facts and nothing else — a log pipeline that can silence a pager eventually will.
How monitoring webhooks work
Uptimia checks your websites from 171+ external locations and, when a check fails, sends an HTTP POST with a JSON body to any URL you register. The same flat object arrives for every kind of check — which monitor, what happened, when, and for how long — so one handler covers all of them, and failed deliveries are retried.
The bug everyone writes on day one
Recoveries, warnings and tests share one endpoint. monitor_status is down, up or test; severity is critical or trouble, and empty on recovery. Branch on both.
Confirmed before your code hears
Automation is only as trustworthy as its trigger. A web check is never alerted on one checkpoint’s opinion — a suspected failure is re-tested from other probes first.
Eleven fields, every event
What is always present, and what it holds.
See every alert channel →| Field | Example | What it holds |
|---|---|---|
| id | 4172 | The monitor's numeric id inside Uptimia |
| monitor_type | uptime | Which kind of check fired |
| monitor_name | Dispatch API | The name you gave it (site name for uptime checks) |
| monitor_unique_id | dispatch-api-eu | Your own identifier — the key to join on |
| monitor_status | down | down, up or test |
| severity | critical | critical or trouble — empty on a recovery |
| incident_start_time | 2026-07-24T02:17:04+02:00 | ISO 8601, account time zone |
| incident_end_time | 2026-07-24T02:31:07+02:00 | Empty while the incident is open |
| incident_duration_seconds | 843 | Zero until the incident closes |
| message | *ALERT*: Project … is DOWN | The one-line summary other channels receive |
| monitor_notes | Failover: drain eu-west-2 first | The monitor's note — empty when nobody wrote one |
Custom webhooks FAQ
01What exactly do you send?+
02How do I authenticate the request?+
03What happens if my endpoint is slow or down?+
04Will I ever receive the same event twice?+
05Can I point it at localhost or an internal address?+
06Do you follow redirects?+
07What arrives when several monitors fail at once?+
08Can my handler acknowledge, or reply?+
09What does “Send test” actually post?+
10How many endpoints can I have, and is it included?+
One URL, every confirmed incident
Register an endpoint, attach it to the monitors that matter, and every confirmed failure arrives as an object your systems can file and act on.