JSON-Payload bei jedem Ereignis
Erhalten Sie einen strukturierten JSON-Body mit Monitor-ID, Status, geprüfter URL, HTTP-Code, Fehlergrund und der phasenweisen Zeitmessung bei jedem Down- und Recover-Ereignis.
Webhooks
Jeder Alert, jeder Endpunkt,
Jeder Alert, jeder Endpunkt,
Ihre Integration.
Senden Sie einen signierten JSON-Payload an einen beliebigen HTTPS-Endpunkt, wenn ein Monitor auslöst: anpassbare Felder, automatische Wiederholungsversuche mit exponentiellem Backoff und Zustellprotokolle, damit Sie jedes Ereignis debuggen können.
Free tier included
No credit card
2-minute setup
Bauen Sie jede Integration auf Webhooks auf.
Webhooks sind das universelle Integrations-Grundelement. Ob Sie Alerts in ein selbst entwickeltes Incident-Tool leiten, Jira-Tickets erstellen oder einen Datadog-Ereignisstrom speisen, der Webhook-Endpunkt ist dort, wo Site Qwality an Ihre Systeme übergibt.
HMAC-SHA256-Signaturen
Jede Zustellung enthält einen X-SiteQwality-Signature-Header. Er ist ein HMAC-SHA256 über die Zustellungs-ID, den Zeitstempel und den rohen Request-Body, mit Punkten verbunden und mit dem Signatur-Secret Ihres Endpunkts geschlüsselt. Der Zeitstempel steckt in der Signatur, eine abgefangene Zustellung kann also nicht gegen Sie wiederholt werden.
Automatische Wiederholungsversuche mit Backoff
Eine fehlgeschlagene Zustellung wird mit exponentiellem Backoff wiederholt, bis zu fünf Wiederholungen über 30 Minuten, bevor sie als fehlgeschlagen markiert wird. Das sind insgesamt sechs Zustellungen: der erste Versuch und fünf Wiederholungen.
Anpassbare Payload-Felder
Wählen Sie, welche Felder im Payload erscheinen, fügen Sie eigene Metadaten hinzu oder filtern Sie Ereignisse nach Schweregrad, damit Ihr Empfänger nur das verarbeitet, was er braucht.
Zustellprotokoll und -inspektor
Jede Zustellung wird protokolliert: der gesendete Request, der Response-Statuscode, ein Auszug des Response-Bodys und die Dauer. Die Einträge werden 30 Tage aufbewahrt. Lesen Sie sie und wiederholen Sie jede Zustellung über die API.
Mehrere Endpunkte pro Monitor
Senden Sie dasselbe Ereignis an mehrere Endpunkte: einen Alert gleichzeitig an einen PagerDuty-Webhook und einen eigenen Audit-Log-Service weiterleiten.
Zuverlässige Zustellung
Wiederholungen, damit Sie
Wiederholungen, damit Sie
kein Ereignis verpassen.
Wenn Ihr Endpunkt nicht erreichbar ist oder einen 5xx zurückgibt, wiederholt Site Qwality 10 Sekunden, 30 Sekunden, 2 Minuten, 8 Minuten und 30 Minuten nach dem ersten Versuch. Ein 4xx wird nicht wiederholt: Gibt Ihr Endpunkt 404 zurück, sagen wir es Ihnen, statt denselben Request fünfmal erneut zu senden. Jeder Versuch wird mit dem HTTP-Status protokolliert.
- Der erste Versuch, dann bis zu fünf Wiederholungen mit exponentiellem Backoff
- Jeder Versuch mit Statuscode und einem Auszug des Response-Bodys protokolliert
- Jede vergangene Zustellung über die API wiederholen
POST /hooks/incident-tool DeliveredLIVE
VERSUCHE2
ENDSTATUS200
SIGNIERTnein
attempt 1timeout
attempt 2200 OK
payload size1.2 KB
signaturenone sent
Vollständiger Ereignis-Payload
Jedes Feld, das Ihre
Jedes Feld, das Ihre
Integration braucht.
Der Payload ist das Prüfergebnis selbst, unter einem data-Schlüssel:
Monitor-ID, Status, geprüfte URL, HTTP-Code, Fehlergrund, Zeitstempel
und die phasenweise Zeitmessung. Genug, um ein Ticket zu
erstellen oder eine Rufbereitschafts-Benachrichtigung ohne nachfolgende API-Aufrufe
zu routen.
- Monitor-ID, Status, URL, HTTP-Code und Fehlergrund in einem Payload
- ISO-8601-Zeitstempel und konsistente Feldnamen über alle Ereignisse
- Eigene Key-Value-Metadaten, die Sie pro Endpunkt definieren
Beispiel-Payload{
"data": {
"http_job_id": "8f1c3a92-5d47-4e1b-9c60-2ab7d5f80e31",
"status": "failed",
"request_uri": "https://api.acme.com/checkout",
"response_http_code": 503,
"failure_reason": "status",
"check_region": "aws-us-east-1",
"request_duration_ms": 184,
"ttfb_ms": 171,
"created_at": "2026-03-14T09:26:53Z"
}
}
"data": {
"http_job_id": "8f1c3a92-5d47-4e1b-9c60-2ab7d5f80e31",
"status": "failed",
"request_uri": "https://api.acme.com/checkout",
"response_http_code": 503,
"failure_reason": "status",
"check_region": "aws-us-east-1",
"request_duration_ms": 184,
"ttfb_ms": 171,
"created_at": "2026-03-14T09:26:53Z"
}
}
Eine Zustellung verifizieren
Die signierte Zeichenkette,
Die signierte Zeichenkette,
und wie Sie sie prüfen.
Die Signatur deckt {delivery_id}.{timestamp}.{roher Request-Body} ab,
nicht den Body allein. ID und Zeitstempel kommen als Header und stecken beide im
MAC: die ID, weil sie Ihr Dedupe-Schlüssel ist, der Zeitstempel, weil eine
Signatur ohne ihn für immer wiederholbar wäre. Prüfen Sie die Aktualität, bevor
Sie den MAC prüfen, und vergleichen Sie in konstanter Zeit.
- Signieren Sie genau die Bytes, die wir gesendet haben, vor dem JSON-Parsen
- Verwenden Sie das Secret wörtlich: kein Base64-Decode, kein Prefix-Stripping
- Rechnen Sie 24 Stunden nach einer Secret-Rotation mit zwei Einträgen, durch Leerzeichen getrennt
verify.js// rawBody muss exakt den gesendeten Bytes entsprechen, vor JSON.parse.
const id = req.headers['x-siteqwality-delivery'];
const ts = req.headers['x-siteqwality-timestamp'];
const sigs = req.headers['x-siteqwality-signature'].split(' ');
// Veraltete Zustellung ablehnen, BEVOR der MAC geprüft wird.
if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return reject();
const expected = 'v1=' + crypto
.createHmac('sha256', secret)
.update(`${id}.${ts}.${rawBody}`)
.digest('hex');
// Zwei Eintraege 24h nach einer Rotation. Konstante Zeit.
const ok = sigs.some(s => s.length === expected.length &&
crypto.timingSafeEqual(Buffer.from(s), Buffer.from(expected)));
const id = req.headers['x-siteqwality-delivery'];
const ts = req.headers['x-siteqwality-timestamp'];
const sigs = req.headers['x-siteqwality-signature'].split(' ');
// Veraltete Zustellung ablehnen, BEVOR der MAC geprüft wird.
if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return reject();
const expected = 'v1=' + crypto
.createHmac('sha256', secret)
.update(`${id}.${ts}.${rawBody}`)
.digest('hex');
// Zwei Eintraege 24h nach einer Rotation. Konstante Zeit.
const ok = sigs.some(s => s.length === expected.length &&
crypto.timingSafeEqual(Buffer.from(s), Buffer.from(expected)));
5
Wiederholungen, bevor eine Zustellung als fehlgeschlagen markiert wird
$0
Webhooks in allen Tarifen, auch im kostenlosen
30d
jede Zustellung protokolliert, mit vollständigem Request und einem Auszug der Response
15s
Request-Timeout je Zustellversuch; danach gilt dieser Versuch als gescheitert
FAQ
Die signierte Zeichenkette ist {delivery_id}.{timestamp}.{roher Request-Body}, mit Punkten verbunden, und der Header-Wert ist v1= gefolgt vom Hex-HMAC-SHA256 dieser Zeichenkette unter dem Signatur-Secret Ihres Endpunkts. Das Secret wird genau so verwendet, wie es Ihnen angezeigt wurde, ohne Base64-Decode und ohne Prefix-Stripping. Zustellungs-ID und Zeitstempel kommen in X-SiteQwality-Delivery und X-SiteQwality-Timestamp, und beide stecken im MAC. Nur über den Body zu signieren ließe eine abgefangene Zustellung wiederholbar. Genau deshalb war der Satz, der hier stand, falsch und hätte einen Verifier erzeugt, der nie passt. Prüfen Sie den Zeitstempel auf fünf Minuten Toleranz, bevor Sie den MAC prüfen, und rechnen Sie 24 Stunden nach einer Secret-Rotation mit mehreren durch Leerzeichen getrennten v1=-Einträgen. Das Snippet oberhalb dieser FAQ erledigt all das.
Sieben Ereignisse feuern: monitor.down, monitor.recover, incident.created, incident.resolved, tls.expiring, dns.expiring und page_speed.degraded. Alle sieben sind standardmäßig aktiv, und Sie können sie pro Endpunkt nach Ereignis oder Schweregrad filtern, damit ein Empfänger nur das verarbeitet, was er braucht.
Site Qwality wiederholt 10 Sekunden, 30 Sekunden, 2 Minuten, 8 Minuten und 30 Minuten nach dem ersten Versuch. Lesen Sie diese Zahlen als Abstände zum ersten Versuch, nicht als Pausen zwischen den Wiederholungen: die letzte landet exakt 30 Minuten danach. Das sind höchstens sechs Zustellungen, der erste Versuch plus fünf Wiederholungen, und eine Zustellung, die 30 Minuten nach dem ersten Versuch nicht geglückt ist, wird als fehlgeschlagen markiert. Danach können Sie sie aus dem Zustellprotokoll wiederholen.
Ja, über die API. Das Zustellprotokoll hält jeden Versuch fest, mit dem gesendeten Request, dem Response-Statuscode, einem Auszug des Response-Bodys und der Dauer, 30 Tage lang. Eine Wiederholung ist eine neue Zustellung mit neuer ID, frischem Zeitstempel und frischer Signatur unter Ihrem aktuellen Secret. Sie sendet also das erneut, was gesendet wurde, nicht das, was die heutigen Einstellungen erzeugen würden.
Ja. Webhooks sind in allen Tarifen einschließlich des kostenlosen enthalten. Es gibt keine Begrenzung der Anzahl von Endpunkten oder Zustellungen in kostenpflichtigen Tarifen.
Related features
Kostenlos starten. Keine Kreditkarte.
Uptime, Cron, Synthetic, Logs, RUM, Incidents und Statusseiten. Kostenlose Stufe bei jedem Produkt.