When does a webhook fire?

On a confirmed state change: once when a monitor goes down and once when it recovers. It sits behind the same confirmation streak as every alert, so a single blip that fixes itself on the next check never fires it.

What's in the payload?

A JSON envelope: event (monitor.status_change), a human-readable text line, monitor and monitor_id, the from and to states, detail and http_status for the cause, downtime_sec on recovery, and at, the time in epoch milliseconds.

Do Slack and Discord use the same webhook?

They're their own channel types. Point them at an incoming webhook URL and the alert arrives as a formatted message; the generic webhook is for endpoints you write yourself and gets the structured envelope.

Are webhooks a paid feature?

No. The webhook family, Slack, Discord, Telegram, and the generic webhook, is free on every plan. You can also route each channel to all monitors or just a few.

Downtime alert webhooks

A JSON POST to your endpoint the moment a monitor changes state.

Get Started Free Read the docs

UptimeX/acme-production

Notifications

Ops webhook · recent alerts

Send test

checkout-api recovered after 31m

monitor.status_change

14:12

checkout-api is down (HTTP 503)

monitor.status_change

13:41

UptimeX test alert: this channel is wired up correctly.

test

09:12

What was sent · 13:41

{
  "event": "monitor.status_change",
  "text": "checkout-api is down (HTTP 503)",
  "monitor": "checkout-api",
  "monitor_id": "kqzvbmxptrwahlucnedj",
  "from": "up",
  "to": "down",
  "detail": "HTTP 503",
  "http_status": 503,
  "downtime_sec": null,
  "at": 1762177267000
}

Built for the endpoint you already run.

A webhook channel is a URL you own. When a monitor changes state, UptimeX POSTs to it: once when a check breaks and once when it recovers, behind the same confirmation streak as every other alert.
Your endpoint hears about the outage, not about every failed check inside it. A single blip that fixes itself on the next check never reaches you, and a thirty-minute outage is two requests, not thirty.
The body is a structured JSON envelope: the event, a human-readable text line ready to forward, and the fields worth branching on. monitor and monitor_id say which, from and to say what changed, detail and http_status say why, downtime_sec arrives on recovery with how long it lasted, and at is the moment in epoch milliseconds.
Open a ticket on to: "down", close it on to: "up", page harder when http_status is a 5xx. The decisions are yours; the facts are in the body.
Slack and Discord don't need the generic envelope at all. Add them as their own channel types, point each at an incoming webhook URL, and the alert arrives as a message formatted for the room, with no receiver to write.
The generic webhook is for the endpoints you write yourself: a serverless function that opens a ticket, a script that flips a feature flag, your own ops bot.
Every channel carries a routing rule. Send everything to one endpoint, or scope a channel to a handful of monitors so the production API's alerts and the staging cron's never share a room.
Send a test through a channel before you rely on it; the test is a plain { "text": … } POST, so a receiver that only acts on event ignores it, which is the point.

Receive it in a few lines

The payload is plain JSON over HTTPS, so the receiving end can be anything that accepts a POST. Read event, branch on to, and answer with a 2xx. Each channel is delivered on its own, so a receiver that is down never holds up Slack or push.

Add the channel from the dashboard, send a test through it, and set its routing rule. The webhook family, Slack, Discord, Telegram, and the generic webhook, is free on every plan, alongside push to the apps.

export default {
async fetch(req) {
  const alert = await req.json();
  if (alert.event === "monitor.status_change") {
    await notifyOps(alert.text, {
      monitor: alert.monitor,
      down: alert.to === "down",
      status: alert.http_status
    });
  }
  return new Response("ok");
}
};

More for developers.

Slack and Discord, without writing a receiver.

Point a channel at an incoming webhook URL and the alert arrives formatted for the room. Route each channel to the monitors it owns.

About notifications

Everything the dashboard does, the API does.

Create, test, update, mute, and delete monitors over HTTPS with a project key. The dashboard is one client of it, not a layer above it.

About the REST API

Your agents get the same API your engineers do.

A remote MCP server with five tools, so Claude or an agent you build can register, check, pause, and remove monitors on its own.

About the MCP server

A reference generated from the API itself.

Every endpoint, parameter, and schema comes from the OpenAPI document the API serves, so the docs can't describe a backend that isn't deployed.

Read the API docs