Webhooks
Real-time monitoring voor Nederlandse infrastructuur
Introduction
Receive instant HTTP POST notifications whenever a monitored endpoint changes status. Configure one or more webhook URLs per check and get notified within seconds of an outage, recovery, or threshold breach — no polling required.
Webhooks are delivered from hooks.statusbewaker.nl with a Retry-After header and automatic back-off. If your endpoint returns a 2xx response, the delivery is marked successful. Non-2xx responses trigger up to 3 retries over 10 minutes. All payloads are JSON-encoded and include a full context object so you can route events to the correct handling pipeline.
Outage Alerts
Triggered the moment a check fails its health criteria. Includes the failing check name, expected response window, and the last successful response time. Ideal for feeding into PagerDuty, Opsgenie, or a custom Slack channel.
Recovery Notifications
Sent when a previously failed check passes its next health evaluation. Contains the duration of the outage in seconds and the timestamp of the successful probe. Use this to close incidents automatically in your ticketing system.
Threshold Breaches
Fires when response time exceeds the configured SLA threshold (e.g., > 800 ms for the Amsterdam probe). The payload carries the measured latency in milliseconds, the probe location, and the configured limit so your alerting rules can act on the severity.
Payload Format
Every webhook POST contains a single JSON body. The top-level keys are event, check, probe, timestamp, and signature. The structure is versioned under schema_version so you can write forward-compatible parsers.
Example payload for an outage event on the api.fortisbank.nl check:
{
"schema_version": "2.1",
"event": "check.failed",
"check": {
"id": "chk_7f3a9b2c",
"name": "fortisbank-api",
"type": "https",
"url": "https://api.fortisbank.nl/v1/status",
"expected_status": 200,
"actual_status": 503,
"last_ok_at": "2025-01-14T08:42:11Z",
"consecutive_failures": 1
},
"probe": {
"location": "ams",
"region": "Netherlands-North",
"latency_ms": null
},
"timestamp": "2025-01-14T08:43:47Z",
"signature": "sha256=a1b2c3d4e5f6..."
}
For a recovery event the event value switches to check.recovered, actual_status returns to 200, and an additional outage_duration_seconds field is appended to the check object. Threshold breach events use event: "check.threshold_exceeded" and populate probe.latency_ms with the measured value alongside a threshold_ms key in probe.
Security
Every webhook request is signed with an HMAC-SHA256 digest so your receiving server can verify the payload originated from StatusBewaker and has not been tampled with in transit.
When you create a webhook endpoint in the dashboard, StatusBewaker generates a 64-character signing secret. This secret is shown once — store it in your application's environment or secrets manager. The signature is sent in the X-StatusBewaker-Signature HTTP header and is also included as the signature key inside the JSON body for convenience.
To verify the signature, compute HMAC-SHA256 over the raw request body using your signing secret as the key. Compare the resulting hex digest against the value provided in the header (prefixed with sha256=). Use a constant-time comparison to prevent timing attacks.
Verification example in Python:
import hmac, hashlib
secret = "whsec_9xK2mP7vQ4nR..."
payload = request.body
header_sig = request.headers["X-StatusBewaker-Signature"]
digest = hmac.new(
secret.encode("utf-8"),
payload,
hashlib.sha256
).hexdigest()
expected = f"sha256={digest}"
assert hmac.compare_digest(expected, header_sig)
If verification fails, reject the request with a 401 response. StatusBewaker will retry according to the same back-off policy described above. You can rotate your signing secret at any time from the webhook settings page — both the old and new secrets are honoured for a 24-hour overlap window to prevent missed deliveries during rotation.