Puls · API- & Webhook-Monitor

Überwacht APIs und Webhooks: Live-Status je Endpunkt, Latenzverlauf, Vorfall-Protokoll mit Statuscode, Antwortzeit und Fehler-Body, Webhook-Simulator und Benachrichtigungen über Slack. Eine Demo von BKS Technologies.

→ Demo öffnen: ohne Anmeldung, die Daten bleiben in Ihrem Browser.

Vorfall im Detail	Webhook-Simulator
Benachrichtigungen	Dunkelmodus

Funktionen

• Übersicht: Tabelle aller Endpunkte mit Status (grün = betriebsbereit, gelb = über der Warnschwelle, rot = Fehler oder keine Antwort), Statuscode, Latenz, p95, Verfügbarkeit und den letzten 30 Prüfungen. Automatische Prüfung alle 15, 30 oder 60 Sekunden.
• Latenzverlauf je Endpunkt mit Warnschwelle und markierten Ausreißern, dazu die letzte Antwort im Klartext.
• Vorfall-Protokoll: Ein Vorfall öffnet sich beim ersten Fehler, zählt Wiederholungen, eskaliert von Warnung zu Ausfall und schließt sich bei der nächsten grünen Prüfung. Detailansicht mit Statuscode, Latenz, Dauer, Error-Body, Antwort-Headern, Zeitleiste und „Als cURL kopieren“.
• Webhook-Simulator: erzeugte Empfangsadresse, Payload-Vorlagen, JSON-Prüfung mit Zeile und Spalte, wählbares Antwortverhalten (202, langsam, 500, 401, 404). Fehlgeschlagene Zustellungen landen im Vorfall-Log.
• Benachrichtigungen: Slack über Incoming Webhooks mit Testnachricht und Versandprotokoll, E-Mail-Empfänger, Auslöser für Ausfall, Warnung und Wiederherstellung.
• Handy-Ansicht, Dunkelmodus, Tastaturbedienung, reduzierte Bewegung.

Was echt ist und was simuliert

Teil	Stand
Prüfungen	echt. /api/check ruft jede URL serverseitig auf und misst die Zeit bis zur Antwort.
Beispiel-Endpunkte	eingebaute Mocks unter /api/mock/<szenario> (stabil, langsam, wackelig, 500, 404, hängt) plus die öffentliche GitHub-API.
Webhook-Empfänger	echt. /api/hooks/<id> antwortet mit 202, 400, 401, 404, 413 oder 500 und speichert nichts.
Slack	echt, über Incoming Webhooks. Die Nachricht baut der Server aus festen Feldern.
E-Mail	nur Konfiguration. Die öffentliche Demo verschickt keine Mails, damit sie kein offener Versandweg ist.
Speicher	keine Datenbank. Endpunkte, Verlauf, Vorfälle und Einstellungen liegen im localStorage des Besuchers.

Sicherheit

Der Prüfdienst ruft URLs im Auftrag anonymer Besucher auf. Er darf deshalb kein Tor ins interne Netz sein (SSRF):

• nur http und https, keine Zugangsdaten in der URL, relative Pfade nur für /api/mock/…
• DNS wird vorab aufgelöst; private, Loopback-, Link-Local-, CGNAT- und Metadaten-Adressen (IPv4 und IPv6) sind gesperrt
• beim Verbindungsaufbau wird noch einmal aufgelöst und geprüft (undici-Agent mit eigenem Lookup), damit DNS-Rebinding nicht greift
• Weiterleitungen werden nicht verfolgt, Timeout höchstens 10 s, Antwort-Body höchstens 4 KB
• Begrenzung je IP und Instanz: 30 Prüfläufe, 60 Webhooks, 10 Slack-Meldungen pro Minute
• Slack-Ziel nur https://hooks.slack.com/services/…
• Sicherheits-Header (X-Frame-Options, nosniff, HSTS, Referrer-Policy, Permissions-Policy)

Technik

Next.js 16 (App Router), React 19, TypeScript, Tailwind CSS 4, Recharts, Lucide, Vitest.

app/                      Seiten und API-Routen
components/<bereich>/     UI je Bereich (dashboard, incidents, simulator, alerts, shell)
components/ui/            Grundbausteine (Panel, Button, Felder, Statusanzeigen)
lib/status.ts             Klassifizierung grün/gelb/rot
lib/incidents.ts          Vorfall-Logik als reine Funktion: öffnen, wiederholen, eskalieren, beheben
lib/store.ts              Client-Speicher (useSyncExternalStore + localStorage), Prüftakt, Alarmversand
lib/server/               Prüfung, SSRF-Schutz, Ratenbegrenzung
tests/                    SSRF-Sperre, Statuslogik, Vorfälle, Kennzahlen

Lokal starten

npm install
npm run dev     # http://localhost:3000
npm test        # 38 Tests
npm run lint
npm run build

Keine Umgebungsvariablen nötig. Auf Vercel läuft das Projekt ohne Einstellungen; vercel.json setzt die Region Frankfurt (fra1).

---

© BKS Technologies UG (haftungsbeschränkt) · Impressum