Senden Sie einen signierten JSON-Payload an einen Endpunkt, den Sie kontrollieren, wenn ein Monitor auslöst: auswählbare Felder, automatische Wiederholungsversuche mit exponentiellem Backoff und ein Zustellprotokoll, damit Sie jedes Ereignis debuggen können.
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.
Jede Zustellung ist ein JSON-Umschlag mit Ereignisname, Schweregrad, Zustellungs-ID und einem data-Objekt. Bei HTTP-Monitoren enthält data das Prüfergebnis: Monitor-ID, Status, geprüfte URL, HTTP-Code, Fehlergrund und die phasenweise Zeitmessung.
Jede Zustellung an eine Webhook-Integration 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, sodass ein Empfänger, der ihn prüft, eine abgefangene und später erneut gesendete Zustellung ablehnen kann.
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.
Wählen Sie, welche Felder des Prüfergebnisses im Payload erscheinen, fügen Sie bis zu zehn eigene Metadaten-Schlüssel hinzu und filtern Sie Ereignisse nach Name oder Mindest-Schweregrad, damit Ihr Empfänger nur verarbeitet, was er braucht.
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 im Dashboard oder über die API.
Senden Sie dasselbe Ereignis an mehrere Endpunkte: einen Alert gleichzeitig an einen PagerDuty-Webhook und einen eigenen Audit-Log-Service weiterleiten.
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.
Jede Zustellung trägt einen Umschlag mit Zustellungs-ID, Ereignisname, Schweregrad,
Zeitstempel und Ihrer Konto-ID. Bei einem HTTP-Monitor steht das Prüfergebnis unter
data: Monitor-ID, Status, geprüfte URL, HTTP-Code, Fehlergrund und die
phasenweise Zeitmessung. Der HTTP-Payload enthält die Monitor-ID, nicht den Namen.
Andere Ereignistypen haben eigene data-Felder.
Die Signatur deckt {delivery_id}.{timestamp}.{raw request body} ab, nicht
nur den Body. ID und Zeitstempel kommen als Header, und beide stecken im MAC: die ID,
weil sie Ihr Schlüssel zur Deduplizierung ist, der Zeitstempel, weil eine Signatur
ohne ihn für immer wiederverwendbar wäre. Prüfen Sie das Alter vor dem MAC und
vergleichen Sie in konstanter Zeit.
Wiederholungen, bevor eine Zustellung als fehlgeschlagen gilt
Webhooks in jedem Plan, auch im kostenlosen
jede Zustellung protokolliert, mit vollständigem Request und Auszug der Response
Timeout pro Zustellversuch, danach geben wir diesen Versuch auf
Die signierte Zeichenkette ist {delivery_id}.{timestamp}.{raw request body}, mit Punkten verbunden, und der Header-Wert ist v1= gefolgt vom hexadezimalen HMAC-SHA256 dieser Zeichenkette mit dem Signatur-Secret Ihres Endpunkts. Das Secret wird genau so verwendet, wie es Ihnen angezeigt wird, ohne Base64-Decoding und ohne Entfernen von Präfixen. Zustellungs-ID und Zeitstempel kommen in X-SiteQwality-Delivery und X-SiteQwality-Timestamp, und beide stecken im MAC. Eine Signatur nur über den Body ließe eine abgefangene Zustellung wiederverwendbar. Prüfen Sie vor dem MAC, ob der Zeitstempel höchstens fünf Minuten alt ist, und erwarten Sie in den 24 Stunden nach einer Secret-Rotation mehr als einen durch Leerzeichen getrennten v1=-Eintrag. Das Snippet über diesen FAQ erledigt all das.
Fünfzehn Ereignisse: monitor.down, monitor.recover, incident.created, incident.resolved, tls.expiring, dns.expiring, dns.record_change, page_speed.degraded, alert.firing, alert.resolved und fünf Ereignisse aus dem Real User Monitoring: rum.issue.created, rum.issue.regressed, rum.issue.escalating, rum.alert.firing und rum.alert.resolved. Alle sind standardmäßig aktiv, und Sie können sie pro Endpunkt nach Ereignis oder Mindest-Schweregrad filtern, sodass ein Empfänger nur verarbeitet, was er braucht. Die Form von data hängt vom Ereignistyp ab. Die beiden Incident-Ereignisse gehen an Webhook-Ziele, die an einem Service eingestellt sind; diese Zustellungen sind nicht signiert und erscheinen nicht im Zustellprotokoll.
Site Qwality wiederholt 10 Sekunden, 30 Sekunden, 2 Minuten, 8 Minuten und 30 Minuten nach dem ersten Versuch. Das sind Abstände zum ersten Versuch, nicht zwischen den Wiederholungen: Die letzte kommt genau nach 30 Minuten. Das sind höchstens sechs Zustellungen, der erste Versuch plus fünf Wiederholungen, und eine Zustellung, die 30 Minuten nach dem ersten Versuch nicht erfolgreich war, wird als fehlgeschlagen markiert. Danach können Sie sie aus dem Zustellprotokoll erneut senden.
Ja, aus dem Zustellprotokoll im Dashboard oder über die API. Das Zustellprotokoll enthält 30 Tage lang jeden Versuch mit dem gesendeten Request, dem Response-Statuscode, einem Auszug des Response-Bodys und der Dauer. Eine Wiederholung sendet den gespeicherten Body erneut, mit neuem X-SiteQwality-Delivery-Header, frischem Zeitstempel und frischer Signatur mit Ihrem aktuellen Secret. Die id im Body bleibt die ursprüngliche; gesendet wird also, was damals gesendet wurde, nicht, was die heutigen Einstellungen erzeugen würden.
Ja. Webhooks sind in jedem Plan enthalten, auch im kostenlosen.
Uptime, Cron, Synthetic, Logs, RUM, Incidents und Statusseiten. Kostenlose Stufe bei jedem Produkt.