Website-Monitoring-Webhook

Wozu ein Webhook

E-Mail und Slack sind feste Ziele. Ein Webhook ist eine einzige Integration, die alles mit einem HTTP-Endpunkt erreicht: Sobald ein Check fehlschlägt, kannst du die Rufbereitschaft alarmieren, ein Ticket mit dem Fehler schon ausgefüllt anlegen oder den Fehler für einen Kundenbericht festhalten – ohne dass jemand Details aus einer E-Mail kopiert.

Jede Anfrage trägt dieselben strukturierten Felder – die Website, den Check, seinen Schweregrad, den Fehler, den Auslöser des Laufs und einen Link darauf –, sodass die Gegenseite entscheiden kann, statt Text zu parsen: jemanden nur bei kritischen Checkout-Fehlern alarmieren, alles andere als Ticket ablegen.

Was du brauchst

Webhook-Alarme gibt es in den Tarifen Pro, Business und Agency.

Du brauchst eine https-Adresse im öffentlichen Internet, die innerhalb von 10 Sekunden mit einem beliebigen 2xx-Status antwortet. Das kann eine kleine eigene Funktion sein oder der Webhook-Trigger eines Automatisierungstools: Der Catch Hook von Zapier, der Custom webhook von Make und der Webhook-Node von n8n nehmen das JSON von Relvato unverändert an.

Schritt 1 – Webhook-URL eintragen

Öffne in Relvato oben rechts das Kontomenü und wähle Alert settings. Füge im Abschnitt Webhook deine Adresse ein und klicke auf Save preferences.

Relvato akzeptiert nur https-Adressen, die ins öffentliche Internet auflösen, und folgt nie Weiterleitungen – nimm also die endgültige Adresse. Beim Speichern entsteht ein Signaturgeheimnis für den Webhook. Wie bei einem Slack-Webhook kann die Adresse ein Token enthalten, deshalb zeigt die Seite nach dem Speichern nur noch den Hostnamen.

app.relvato.com/alerts

Schritt 2 – Signaturgeheimnis kopieren

Klicke neben Signing secret auf Show, dann auf Copy, und lege es dort ab, wo dein Empfänger es lesen kann – zum Beispiel in einer Umgebungsvariable namens RELVATO_WEBHOOK_SECRET. Es beginnt mit whsec_.

Rotate erzeugt sofort ein neues Geheimnis; das alte verifiziert dann nicht mehr, also aktualisiere deinen Empfänger gleichzeitig.

Schritt 3 – Test senden

Klicke unten auf der Seite auf Send test webhook. Relvato sendet ein Ereignis vom Typ test, signiert wie ein echtes, und sagt dir, ob dein Endpunkt geantwortet hat – etwa „Test event delivered (HTTP 200)“. Falls nicht, nennt die Meldung den Grund: keine Antwort binnen 10 Sekunden, eine Weiterleitung oder den Status, den dein Endpunkt zurückgab.

Schritt 4 – Festlegen, was an den Webhook geht

Unter What goes where hat die Spalte Webhook einen Schalter pro Check-Typ – User flows, Security, Design, Performance, SEO / AEO, Domain lifecycle und Other. Schalte die aus, die du nicht in deinen Tools haben willst; E-Mail und Slack haben eigene Schalter.

Der Rest der Alert settings gilt ebenfalls: Sites bestimmt, welche Websites alarmieren, und Alert me on legt den niedrigsten Schweregrad fest, der verschickt wird. Der Webhook ist sofort – lass As it happens angehakt; die täglichen und wöchentlichen Zusammenfassungen gibt es nur per E-Mail.

app.relvato.com/alerts

Was Relvato sendet

Jeder Alarm ist ein POST mit Content-Type: application/json und drei Headern: Relvato-Event (der Ereignistyp), Relvato-Delivery (eine eindeutige ID, die bei einem erneuten Zustellversuch gleich bleibt, damit du Duplikate ignorieren kannst) und Relvato-Signature.

Es gibt vier Ereignistypen: check.failed, wenn ein Check zu scheitern beginnt (oder scheitert, wenn du ihn selbst startest), check.passed, wenn „Tell me about every run“ aktiv ist, quarantine.change für die Start-, Änderungs- und Abschlussmeldungen des Quarantäne-Modus, und test über den Button oben. Alle haben dieselbe Form; Teile, die nicht zutreffen, sind null.

app.relvato.com/alerts

Signatur prüfen

Relvato-Signature sieht so aus: t=1790000000,v1=… – t ist die Unix-Zeit der Anfrage und v1 ein HMAC-SHA256 mit deinem Signaturgeheimnis über den Zeitstempel, einen Punkt und den rohen Anfrage-Body. Berechne ihn über den Body genau so, wie er ankam (nicht über neu serialisiertes JSON), vergleiche in konstanter Zeit und lehne Zeitstempel ab, die älter als fünf Minuten sind – so lässt sich eine abgefangene Anfrage später nicht wiederholen.

Der Webhook-Trigger eines Automatisierungstools kann Signaturen meist nicht prüfen. Für risikoarme Zwecke wie ein Protokoll ist das in Ordnung; wenn ein Webhook Incidents öffnen oder etwas ändern kann, setze eine kleine Funktion davor, die die Signatur prüft.

import crypto from "node:crypto";
import express from "express";

const app = express();

// Keep the RAW body: the signature is over the exact bytes Relvato sent.
app.post("/relvato-webhook", express.raw({ type: "application/json" }), (req, res) => {
  const header = req.get("Relvato-Signature") ?? "";      // "t=1790000000,v1=5f2c…"
  const t = Number(/t=(\d+)/.exec(header)?.[1]);
  const v1 = /v1=([0-9a-f]{64})/.exec(header)?.[1] ?? "";
  const expected = crypto
    .createHmac("sha256", process.env.RELVATO_WEBHOOK_SECRET)
    .update(`${t}.${req.body}`)
    .digest("hex");
  const fresh = Math.abs(Date.now() / 1000 - t) < 300;    // refuse replays older than 5 minutes
  if (!fresh || v1.length !== 64 ||
      !crypto.timingSafeEqual(Buffer.from(v1), Buffer.from(expected))) {
    return res.sendStatus(401);
  }
  const event = JSON.parse(req.body.toString());
  res.sendStatus(200);                                     // answer fast, then do the slow work
  handle(event);                                           // switch on event.type
});

Praxisbeispiele

Die Rufbereitschaft alarmieren. Schicke check.failed-Ereignisse an n8n oder Make, behalte die mit Schweregrad critical – ein kaputter Checkout oder Zahlungsschritt – und lege in PagerDuty oder Opsgenie einen Incident mit Website, Fehler und Link zum Lauf an.

Automatisch ein Ticket anlegen. Ein Zapier Catch Hook macht aus jedem Fehler ein Jira-, Linear- oder GitHub-Issue: der Check-Name als Titel, Fehler und Änderungen in der Beschreibung, der Link zum Lauf zum Nachvollziehen.

In Microsoft Teams, Discord oder Google Chat posten. Diese erwarten ihr eigenes Nachrichtenformat – leite den Webhook über Make, n8n oder Zapier und ordne die Felder von Relvato der Nachricht zu.

Ein Fehlerprotokoll für Kundenberichte führen. Hänge pro Ereignis eine Zeile an Google Sheets oder dein Data Warehouse an und berichte dann, wie oft jede Website ausfiel, welche Checks betroffen waren und wie lange Korrekturen dauerten.

Agenturen: nach Website verteilen. Jedes Ereignis enthält site.id und site.name, so kann ein einziger Webhook die Alarme jedes Kunden in dessen Kanal oder Projekt schicken.

Auf ein fehlerhaftes Deployment reagieren. Kommt check.failed mit einem Deploy als Auslöser, kann deine Pipeline einen Revert-Pull-Request zur Freigabe öffnen – lass einen Menschen entscheiden, bevor sich auf der Live-Website etwas ändert.

Wiederholungen, Duplikate und Pausieren

Antwortet dein Endpunkt nicht, braucht er länger als 10 Sekunden oder liefert er 5xx oder 429, versucht Relvato es nach 2 Sekunden und nach 8 Sekunden erneut. Andere 4xx-Status und Weiterleitungen werden nicht wiederholt – die Antwort würde sich nicht ändern. Jede Zustellung wird am Lauf protokolliert, und eine fehlgeschlagene zeigt ihren Grund in den Alert settings.

Ein erneuter Versuch trägt dieselbe Relvato-Delivery-ID. Speichere die IDs, die du verarbeitet hast, und überspringe Wiederholungen.

Nach 20 fehlgeschlagenen Zustellungen in Folge pausiert Relvato den Webhook und sagt es dir: Die Benachrichtigungsglocke zeigt „Webhook alerts paused“ mit dem letzten Fehler, und die Alert settings zeigen es mit einem Button Resume. Repariere den Empfänger und klicke auf Resume.

Webhook ändern oder entfernen

Um ihn woanders hinzuschicken, füge die neue Adresse ein und speichere; das Signaturgeheimnis bleibt gleich. Um den Versand zu stoppen, ohne die Einrichtung zu verlieren, entferne den Haken bei Send alerts to the webhook. Um ihn ganz zu entfernen, hake Remove on save an und klicke auf Save preferences – Relvato löscht Adresse und Signaturgeheimnis; Details stehen in der Datenschutzerklärung.