Email and SMS alerts are useful, but they end at your inbox. Webhook notifications go further — ServerVisor sends an HTTP POST to a URL you control, with a structured JSON payload, the moment something happens. Your systems receive the event directly and can act on it however makes sense for your infrastructure.
What events fire a webhook
ServerVisor fires a webhook for four event types, each covering a different category of monitoring failure:
- site_down — a domain has become unreachable across one or more monitoring locations
- site_up — a domain has recovered after a site_down event
- ssl_expiring — an SSL certificate is approaching its expiration date
- heartbeat_missed — a scheduled job or background process has not checked in within its expected window
Each event includes a timestamp and the data relevant to that specific alert type. A site_down event tells you which domain went down, how many monitoring locations are reporting the failure, when the incident opened, and the last HTTP status code seen. A site_up event tells you how long the outage lasted. This gives your receiving system enough context to act without making additional API calls.
What the payload looks like
Every delivery is an HTTP POST with a JSON body. The envelope is the same across all event types — an event name, a timestamp, and a data object with event-specific fields:
{
"event": "site_down",
"fired_at": "2026-07-03T14:22:00+00:00",
"data": {
"domain": "example.com",
"incident_id": 4821,
"affected_locations": 3,
"total_locations": 5,
"started_at": "2026-07-03T14:21:47+00:00",
"last_status_code": 503
}
}Your endpoint receives this, does whatever it needs to do, and returns any 2xx response. ServerVisor treats that as a successful delivery. The whole interaction is standard HTTP — no SDKs, no proprietary protocol.
Setting up a webhook endpoint
Go to Settings → Integrations → Webhooks and create a new endpoint. You provide a URL — it must be publicly reachable over HTTPS — and optionally a signing secret. Once saved, attach the webhook to one or more monitors via that monitor's notification settings. From that point, every qualifying event on those monitors triggers a delivery to your URL.
You can attach the same webhook endpoint to multiple monitors, and a single monitor can have multiple webhook targets. This lets you fan out alerts to different systems — for example, sending all downtime events to both your incident management tool and a custom logging endpoint — without duplicating the endpoint configuration.
Verifying the signature
When you set a signing secret on a webhook endpoint, ServerVisor includes an X-SV-Signature header with every delivery. The value is an HMAC-SHA256 of the raw request body, computed with your secret. Your endpoint can verify it before processing the payload to confirm the request came from ServerVisor and has not been tampered with.
<?php
$raw_body = file_get_contents('php://input');
$secret = getenv('SERVERVISOR_WEBHOOK_SECRET');
$expected = 'sha256=' . hash_hmac('sha256', $raw_body, $secret);
$received = $_SERVER['HTTP_X_SV_SIGNATURE'] ?? '';
if (!hash_equals($expected, $received)) {
http_response_code(401);
exit;
}
$payload = json_decode($raw_body, true);
// handle $payload['event'] ...What you can build with it
Webhook notifications are most useful when you want monitoring events to flow into systems that already exist rather than adding a new alerting tool. Some common patterns:
- Post to a custom Slack channel with exactly the message format your team uses, including links to runbooks or dashboards for that specific service
- Open or update an incident in PagerDuty, OpsGenie, or your own incident tracking system, populating fields automatically from the payload
- Trigger a remediation script — restart a service, flush a cache, scale up capacity — when a specific monitor reports down
- Write downtime events to your own database or analytics pipeline alongside application logs, so you can correlate outages with deployments or traffic spikes
- Update a public or internal status page without running a separate polling process
- Fan out to multiple destinations by having your endpoint forward the event wherever it needs to go
The receiving endpoint can be a route in an existing application, a serverless function, or a small standalone script — whatever fits your stack. ServerVisor does not care what you do with the payload once it is delivered. You own the response logic entirely.