Monitoring webhooks with a contract you build on.
Every confirmed failure leaves as a flat JSON object POSTed to your URL — the same eleven fields for all twelve monitor types, retried five times if your endpoint does not answer 2xx.
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 all twelve monitor types: write one handler, branch on two fields. It is retried five times before it drops, so duplicates are possible — documented rather than discovered.
Nobody was woken, nothing lost
At 02:17 a dispatch node at a logistics company starts timing out. The only thing awake is ops-bridge — forty lines that receive Uptimia’s POST and decide what happens next.
A URL and a header
No app to authorise, no library to install. Uptimia needs somewhere to POST and, if the endpoint is protected, whatever gets it through the door.
Register the endpoint
Add a Webhooks integration under Alerting → Integrations and paste the URL. It must be public http(s), and redirects are not followed — so register the URL that actually answers.
Add whatever gets you past the door
Optional, and sent exactly as written: one per line, Name: value. That is where a token goes. There is no body signature, so the URL is a credential too.
Attach it, then prove it answers
A webhook is a contact like any other: attach it to the monitors you want and it fires on their next confirmed incident. Send test posts the real shape with placeholder values.
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.
- Adding a webhook
- Adding custom headers
- Sending a test
- Attaching the webhook to monitors
- Troubleshooting
Twelve monitor types. One payload 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 — twelve monitor types, 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 body is a flat object of eleven fields: id, monitor_type, monitor_name, monitor_unique_id, monitor_status, severity, incident_start_time and incident_end_time as ISO 8601 timestamps, incident_duration_seconds, a one-line message, and monitor_notes — the note the person who set the monitor up wrote for whoever picks the incident up. The same shape arrives for all twelve monitor types, so one handler covers every one. Your endpoint has ten seconds to answer; any 2xx means accepted, anything else is retried up to five times.
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 of the twelve check types 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.