Native channel: Webhooks
The native webhook channel POSTs a structured JSON body the instant a monitor fails, and again when it recovers. Route it into your own services, a queue, a logger, or any tool that speaks HTTP. No middleware, no polling.
Works on every paid plan. 14-day trial, no card required.
{
"event": "monitor.down",
"monitor": { "name": "Checkout API", "url": "https://api.acme.io/v2/checkout", "type": "API" },
"error": "Down from 2/3 locations: London, New York",
"locations": [
{ "locationCode": "LHR", "city": "London", "isUp": false, "statusCode": 503, "responseMs": 8412 },
{ "locationCode": "NYC", "city": "New York", "isUp": false, "statusCode": 503, "responseMs": 8120 },
{ "locationCode": "SYD", "city": "Sydney", "isUp": true, "statusCode": 200, "responseMs": 1290 }
],
"timestamp": "2026-10-14T09:41:07.000Z"
}The generic webhook channel needs nothing more than a URL that accepts a POST. If your endpoint can read JSON, you are ready.
In the dashboard, open Alert Contacts, click Add contact and choose Webhook.
Enter the endpoint in Webhook URL (http:// or https://). Requests are not signed, so put a long random token in the path or query string and check it in your handler.
Tick the contact under Notify on failure on each monitor, across any of the 9 types. A monitor with nothing ticked alerts every contact.
Click Send test. Your endpoint receives a small request with event set to test, and must reply with a 2xx status.
The body is deliberately flat and predictable so your handler can act on it without guesswork. Here is every field you can rely on.
| Field | Type | Meaning |
|---|---|---|
| event | string | monitor.down when a monitor goes down, monitor.up when it recovers. |
| monitor.name | string | The name you gave the monitor. |
| monitor.url | string | The endpoint or host being watched. |
| monitor.type | string | HTTP, KEYWORD, TCP_PING, PORT, API, HEARTBEAT, SSL, DNS or DOMAIN_EXPIRY. |
| error | string | null | What failed, for example which locations. On recovery it is null, or the latest check result for heartbeat, SSL, DNS and domain expiry monitors. |
| downDuration | string | On recovery, how long the monitor was down, for example 11m 26s. Left out of monitor.down events. |
| locations | array | The latest result from each location: locationCode, city, isUp, statusCode, responseMs. Empty for heartbeat, SSL, DNS and domain expiry monitors. |
| timestamp | string | ISO 8601 UTC time the alert was sent. |
Two events share one shape. The event field tells them apart, and recovery adds downDuration, so a single handler covers both the incident and the all-clear.
{
"event": "monitor.down",
"monitor": { "name": "Marketing Site", "url": "https://www.example.com", "type": "HTTP" },
"error": "Down from 2/3 locations: London, New York",
"locations": [
{ "locationCode": "LHR", "city": "London", "isUp": false, "statusCode": 503, "responseMs": 8412 },
{ "locationCode": "NYC", "city": "New York", "isUp": false, "statusCode": 503, "responseMs": 8120 },
{ "locationCode": "SYD", "city": "Sydney", "isUp": true, "statusCode": 200, "responseMs": 1290 }
],
"timestamp": "2026-10-14T09:41:07.000Z"
}{
"event": "monitor.up",
"monitor": { "name": "Marketing Site", "url": "https://www.example.com", "type": "HTTP" },
"error": null,
"downDuration": "11m 26s",
"locations": [
{ "locationCode": "LHR", "city": "London", "isUp": true, "statusCode": 200, "responseMs": 182 },
{ "locationCode": "NYC", "city": "New York", "isUp": true, "statusCode": 200, "responseMs": 431 },
{ "locationCode": "SYD", "city": "Sydney", "isUp": true, "statusCode": 200, "responseMs": 1264 }
],
"timestamp": "2026-10-14T09:52:33.000Z"
}Webhooks are one of eight channels built directly into PulseStack. Use them alone or alongside any of the others on the same monitor.
SMS alerts are included on the Team and Enterprise plans. Zapier and Google Chat connect through this webhook channel rather than as native integrations. See all integrations.
Whatever you watch, the same JSON contract applies. Attach the webhook channel to any of these nine. SSL, DNS, domain expiry and heartbeat checks run from one server, so their locations array is empty.
Status codes, response time and content checks for any URL.
Confirm a phrase is present, or fire when it disappears.
Timed TCP connection checks to any host and port.
Watch a specific TCP port on SMTP, database or custom services.
Requests with custom headers and body, checked against the expected status.
Cron and background jobs check in, silence raises an alert.
Fires a set number of days before expiry (7 by default), or when the certificate is not trusted.
Fires when no record of the chosen type holds the value you expect.
Fires a set number of days before the registration runs out (7 by default).
Pipe events into an internal router that already knows who is on rota, and let it decide who to page.
Append each payload to a data store or observability pipeline to build your own uptime history and audit trail.
Kick off a script that restarts a service, flushes a cache or fails over, the moment a down event lands.
Point the webhook at a Zapier Catch Hook and branch into the other apps your Zapier account connects. See the Zapier setup.
Use a Google Chat space webhook URL: PulseStack™ spots chat.googleapis.com and sends a plain text message the space can show. See the Google Chat setup.
Have your receiver flip a tile on an internal dashboard so the whole team sees state without logging in.
50 monitors, 60s checks, all monitor types, SSL, DNS and domain insights.
150 monitors, 30s checks and competitor tracking.
500 monitors, 30s checks, server diagnostics, 3 seats and SMS alerts.
2,000 monitors, 30s checks, 5 seats, SMS and PDF reports.
The Free plan covers 5 HTTP monitors with email alerts. Every paid plan starts with a 14-day trial and needs no card up front.
Start with Send test next to the contact on the Alert Contacts page. Your endpoint should receive the request below and answer with a 2xx; any other reply shows as Webhook returned and the status code, for example Webhook returned 500.
{
"event": "test",
"message": "This is a test notification from PulseStack.",
"timestamp": "2026-10-14T09:30:00.000Z"
}The test request has event set to test and no monitor object, unlike real alerts. A handler that insists on monitor.down or monitor.up fields may answer 400 and make the test fail, so accept or ignore event test.
PulseStack™ posts each alert once and does not retry, and a failed delivery is not reported back to the dashboard. Reply with a 2xx straight away, queue any slow work, and check your own server logs for missed requests.
Requests follow up to five redirects, and only to public addresses, but a 301 or 302 turns the POST into a GET without the JSON body. Use the final URL, including https:// and any trailing slash your server expects.
Alerts are sent from PulseStack™'s servers, so an address that only works on your own machine or network (localhost, a 192.168.x.x address, a VPN-only host) cannot receive them. The form refuses private, internal and reserved addresses when you save, and every alert checks the address again when it is sent, so a hostname that later points at a private address is not called.
Alerts go to the contacts ticked under Notify on failure (every contact if none are ticked), and only when a monitor goes down or recovers. If an alert looks wrong, see why a monitor status can be wrong.
On each alert PulseStack™ POSTs a JSON payload containing the event, the monitor (its name, URL and type), the error, how long it was down (recovery only), the latest result from each location and a timestamp. You can parse that body and route it into any system you run.
Alerts fire on both failure and recovery. A failed check is re-tested a few seconds later, and a monitor is only marked down when at least two of the three check locations fail, so a single blip never triggers a page, while a genuine outage still alerts quickly.
Yes. Zapier Catch Hooks and most automation tools take the JSON payload as it is. Google Chat is handled for you: when the URL starts with https://chat.googleapis.com/, PulseStack™ sends a plain text message instead, because Google Chat rejects fields it does not know.
All of them. All nine monitor types can route their alerts through the Webhook channel: HTTP, Keyword, TCP Ping, Port, API, Heartbeat, SSL certificate, DNS record and domain expiry.
Webhooks are one of the eight native alert channels, but the free plan sends email alerts only. It includes 5 monitors with HTTP checks, and paid plans add all monitor types, more alert channels and a 14-day trial with no card needed, so you can wire webhooks into your full setup.
No. You only need a URL that accepts an HTTP POST from the internet, such as a serverless function or an API route on your own server. PulseStack delivers the payload directly with no polling or extra infrastructure in between.
No. PulseStack™ does not sign requests or add an authorisation header. Put a long random token in the URL path or query string and have your handler reject any request without it.
Add the webhook channel, attach it to your monitors and start receiving structured JSON on failure and recovery. It takes minutes.