Alerts & Benachrichtigungen

Unter /app/alerts sehen Sie alle Monitoring-Alarme an einem Ort — gefiltert nach Status (aktiv, behoben, alle) und Schweregrad. Ein Klick öffnet die Detailansicht mit Verlauf (ausgelöst, bestätigt, behoben), Zustellkanälen, der betroffenen Website und — falls vorhanden — dem verknüpften Incident. Dort bestätigen, beheben oder löschen Sie einzelne Alarme und laden ein Postmortem herunter. Gebündelte Vorfälle (Incidents) bleiben unter /app/incidents.

HTML-Variante mit Schweregrad-Hervorhebung und Dashboard-Link, automatischer Plain-Text-Fallback. Versand vom EU-Mail-Server (Deutschland, DSGVO-konform), Reply-To zentral auf mail@xictraq.com gesetzt.

Native, optisch sauber formatierte Nachrichten — keine generischen Webhook-Posts. Acknowledge- und Open-in-Dashboard-Buttons direkt in Slack, in Discord und Teams als Links in der Nachricht (deren Webhooks zeigen keine Knöpfe), ohne dass Empfänger sich im Dashboard einloggen müssen (signierter One-Click-Token, läuft nach 14 Tagen ab). Alle eingehenden Texte (Titel, Nachricht, Website-Name) werden kanalgerecht escaped, damit eingeschleuste Links oder Steuerzeichen nicht gerendert werden.

Mit Bot-Token von @BotFather und Chat-ID eingerichtet (Chat-ID z. B. über @userinfobot). HTML-formatierte Messages, alle User-Strings escaped.

JSON-POST an eine beliebige URL bei jedem Vorfall. Das Event heißt alert.opened beim Auslösen und alert.resolved beim Auflösen. Pro Account ein rotierbares Webhook-Secret (64 Hex-Zeichen): ist es gesetzt, signiert XICTRAQ den Body per HMAC-SHA256 und sendet die Signatur im Header X-Xictraq-Signature, sodass Empfänger die Authentizität prüfen können. Jede Auslieferung wird mit HTTP-Status, Antwort-Auszug, Laufzeit und Signatur-Flag protokolliert — bei Bedarf manuell per Resend-Button erneut auslösen oder das Secret rotieren. Ziel-URLs werden gegen interne/private Adressen geschützt (SSRF-Härtung).

Der AlertDeliveryService führt pro Kanal bis zu 2 Retries mit Backoff (0,5 s → 1,0 s) durch — aber nur, wenn keine Auslieferung stattgefunden haben kann: HTTP 429, keine Antwort (HTTP 0) oder ein reiner Verbindungsfehler (DNS/Connect). Bereits zugestellte 5xx/408-Antworten und 4xx-Fehler (z. B. ungültige Slack-URL) werden nicht wiederholt. Das Per-Channel-Ergebnis (status, http, error, attempts) landet als JSON in alerts.delivery_log; im Vorfalls-Detail können Sie pro Kanal sehen, was passiert ist.

Eingeloggte Nutzer können sich pro Gerät für Web-Push registrieren (VAPID, selbst gehostet — kein Firebase, kein OneSignal). Der siebte Kanal — anders als die übrigen wird er pro Gerät aktiviert und nicht pro Kategorie geschaltet. Ideal für Stand-by-Sessions im Browser-Tab. Verwaltung pro Gerät unter /app/settings/notifications.

Bei zustand-basierten Befunden (z. B. Mixed Content, defekte Links, fehlende E-Mail-Auth, Blacklist-Listung, robots.txt blockiert alles) und schwellenwert-basierten Verschlechterungen (SSL-/Domain-Ablauf, visuelle Änderung) gilt zusätzlich eine Abklingzeit: Wurde derselbe Typ für eine Website kürzlich aufgelöst, wird er nicht sofort erneut alarmiert. Das verhindert Spam durch flatternde Dauer-Probleme. Die Vorgabe sind 24 Stunden; unter /app/settings/notifications lässt sich die Abklingzeit zwischen 6 Stunden und 7 Tagen wählen oder abschalten.

Unter /app/settings/notifications stellen Sie ein, wie lange eine Website am Stück nicht erreichbar sein muss, bevor ein Ausfall-Alarm rausgeht (0 bis 900 Sekunden). Standard ist „automatisch“: das doppelte Prüfintervall der jeweiligen Website, mindestens 2 und höchstens 15 Minuten – bei 5 Minuten Prüfintervall also 10 Minuten. Wer jeden Ausfall sofort gemeldet haben will, stellt 0 ein. Gemessen wird ab dem letzten erfolgreichen Check; läuft die Karenz noch, entscheidet der nächste Check erneut. Damit dämpfen Sie kurze Aussetzer, ohne die Prüfintervalle zu verlängern. Die Einstellung gilt kontoweit und für beide Prüfpfade (Monitoring-Nodes und On-Demand-Scan).

Ebenfalls unter /app/settings/notifications: Fällt der Security-Score einer Ihrer Websites unter den eingestellten Mindestwert, entsteht genau ein offener Alarm vom Typ security_score_drop — nicht bei jedem Scan ein neuer. Steigt der Score wieder über die Schwelle, löst die Entwarnung ihn automatisch auf. Während eines Wartungsfensters entsteht kein neuer Alarm.

Die Kategorien sind Uptime, SSL, Security, Compliance, SEO, Performance, Konkurrenz, Reports und System. Für jede legen Sie fest, ob sie aktiv ist und über welche der sechs Kanäle sie zugestellt wird. Standardmäßig geht alles per E-Mail; Uptime zusätzlich auf alle aktiven Push-Kanäle, da Ausfälle am dringlichsten sind. Test-Alerts gehen unabhängig von den Einstellungen immer durch.

Meldet der Tracker denselben Browser-Fehler aus echten Besuchen zum fünften Mal, entsteht ein Alarm der Schwere Warnung in der Rubrik „Performance und JS-Fehler“. Je Website und Fehlermeldung gibt es einen offenen Alarm mit dem Fehlertext im Titel; weitere Sichtungen zählen darin hoch. Tritt der Fehler sieben Tage nicht mehr auf, schließt XICTRAQ den Alarm mit Entwarnung. Bekanntes Rauschen löst keinen Alarm aus, etwa Fehler aus Browser-Erweiterungen, allgemeine Fehler ohne Quelldatei oder Module, die nach einem Deploy nicht mehr laden; erfasst werden sie trotzdem.

In der Rubrik „Änderungen und Analytics“ stehen die Alarme der Shopware-Anbindung: „Shop-Anbindung fehlgeschlagen“ (shop_integration_failed), wenn der tägliche Abruf des Patchstands zweimal in Folge scheitert, und „Bestellimport fehlgeschlagen“ (shop_import_failed), wenn der Bestellimport zweimal in Folge mit demselben Fehler endet oder seit mehr als 60 Minuten keinen Abgleich geschafft hat. Beide geben beim nächsten Erfolg Entwarnung. Die Erfassungsquote (tracker_coverage_drop) ist ein Hinweis der automatischen Anomalie-Erkennung: Liegt der Anteil der Online-Bestellungen, die der Tracker erfasst, in den letzten drei Tagen unter 80 % seines Werts der 28 Tage davor, steht ein Hinweis der Schwere Warnung im Dashboard, unter 40 % der Schwere kritisch; wie jeder solche Hinweis kommt er zusätzlich als Alarm „Analytics-Anomalie“.

Für die Kategorie Konkurrenz steuern Sie zusätzlich, welche Änderungsarten überhaupt benachrichtigen — etwa Technik-Wechsel, Security-Vorfall, Preisänderung oder Stellenanzeigen. Marketing-nahe Signale (Messaging-, WAF-, Anzeigen- oder CTA-Änderungen) sind im Standard stummgeschaltet, um Rauschen zu vermeiden.

Diese beiden Kategorien melden sich nicht in Echtzeit. Konkurrenz-Änderungen sammelt XICTRAQ und schickt sie einmal täglich um 8:00 Uhr als einen Bericht, Wochen- und Monatsberichte gehen zum eingestellten Termin. Die E-Mail enthält die vollständige Auswertung; auf den übrigen Kanälen steht eine kurze Meldung mit dem Link ins Dashboard. Auch hier gilt die Kategorie-Einstellung: Schalten Sie die E-Mail ab, entsteht der Bericht trotzdem und liegt im Dashboard bereit.

Jede Policy hat bis zu 10 Stufen, jeder Account bis zu 20 Policies. Stufe 1 ist die Erstmeldung (sofort, über Ihre Default-Kanäle). Jede Folgestufe trägt einen Zeitversatz (delay_minutes, 0 bis 1440 = bis zu 24 Stunden) relativ zum Vorfallsbeginn sowie eine eigene Kanal-Auswahl aus den sechs pro Stufe konfigurierbaren Kanälen (E-Mail, Slack, Discord, Telegram, Teams, Webhook) — Browser-Push lässt sich hier nicht einzeln setzen.

Pro Stufe wählen Sie, wer benachrichtigt wird: eine feste Kontakt-Adresse (static), der gerade diensthabende Kollege aus einem On-Call-Schedule (on_call) oder alle Team-Mitglieder mit einer Rolle (team_role: admin, editor, viewer). Maßgeblich ist die Rolle auf der Website des Alarms, auch wenn eine Einladung dort eine abweichende Rolle vergibt; jede Adresse bekommt die Stufe je Kanal einmal. So eskaliert Stufe 1 z. B. an die Bereitschaft, Stufe 2 nach 15 Minuten an alle Team-Admins.

Eine Policy lässt sich auf einzelne Websites und eine Mindestschwere (ab Warnung, nur kritisch) beschränken. Passende Alarme übernimmt dann die engste Policy: zuerst eine mit Website-Auswahl, dann die mit der höheren Schwelle, erst danach die Standard-Policy. Der Zuschnitt gilt auch für eine Policy, die ein Bereitschaftsplan für den Tag aktiviert; passt sie nicht, greift die normale Auswahl. Ohne Zuschnitt wirkt eine Policy nur als Standard oder über den Bereitschaftsplan.

Schedules definieren Schichten in Ebenen (layers) mit Rotation täglich, wöchentlich oder fest und optionalen Einschränkungen (bestimmte Wochentage + Uhrzeitfenster). Wer gerade Dienst hat, wird live aufgelöst — inklusive Urlaubs-/Ausnahme-Overrides (oncall_overrides), die einen Kollegen temporär ersetzen. Verwaltung unter /app/settings/on-call. Zeitzone pro Schedule (Default Europe/Berlin).

Pro Wochentag lässt sich ein anderer Modus festlegen: eine abweichende Eskalations-Policy aktivieren, eine zusätzliche Bereitschafts-E-Mail mitschicken oder beim Standard bleiben. So fährt das Wochenende eine andere Empfänger-Route als die Werktage, ohne die Default-Konfiguration anzufassen.

Die Acknowledge-Knöpfe und -Links in Slack, Discord, Teams und E-Mail öffnen einen signierten One-Click-Link (HMAC-signiert, 14 Tage gültig). Ein Klick markiert den Vorfall als bestätigt und beendet jede weitere Eskalationsstufe sofort — der Empfänger muss sich dafür nicht im Dashboard einloggen.

In der Detailansicht unter /app/alerts lässt sich ein offener, noch nicht bestätigter Alarm für 1, 4, 8 oder 24 Stunden stummschalten. Solange die Stummschaltung läuft, rückt keine Eskalationsstufe nach und es gehen keine Erinnerungen hinaus; danach geht es an der Stelle weiter, an der der Alarm stand. Der Alarm bleibt offen, in der Liste steht er als „Stumm“, und die Zeitleiste hält fest, wer ihn wann stummgeschaltet oder die Stummschaltung wieder aufgehoben hat.

Unter /app/settings/notifications lässt sich einstellen, dass ein offener Alarm der Stufe Warnung oder Kritisch in festem Abstand erneut gemeldet wird – alle 30 Minuten bis täglich. Die Erinnerung trägt den Vorsatz „Erinnerung:“ im Titel, geht nur an die Kanäle, die den ersten Alarm bekommen haben, und nie an den Webhook. Sie endet mit dem Bestätigen oder Beheben, nach zehn Erinnerungen oder sieben Tagen nach dem Alarm. Ruhezeiten, Wartungsfenster und Stummschaltungen gelten auch für Erinnerungen. Erinnert wird nur an Alarme, die nach dem Einschalten entstanden sind.

Zwei Varianten: ein einmaliges Fenster mit konkretem Start- und Endzeitpunkt (für einen geplanten Relaunch) oder ein wöchentlich wiederkehrendes Fenster (Wochentag + Start-/Endzeit). Die Unterdrückung folgt einer festen Reihenfolge: einmaliges Fenster vor wöchentlichem Website-Fenster vor kontoweitem Fenster. In dieser Zeit laufen die Checks weiter, Alerts werden aber unterdrückt. Verwaltung unter /app/settings/maintenance.

Pro Kanal definierbar (z. B. Telegram nur 08:00 bis 22:00, sonst nur E-Mail). Es lassen sich mehrere Zeitfenster mit Wochentagen und eine eigene Zeitzone hinterlegen; auch über Mitternacht reichende Fenster (z. B. 22:00 bis 07:00) werden korrekt erkannt. Anders als Wartungsfenster unterdrücken Quiet Hours nur die Zustellung über den betroffenen Kanal, nicht den Vorfall selbst — kritische Alerts gehen immer durch. Nach dem Ende der Ruhezeit kommt je Kanal eine Sammelmeldung mit den ausgelassenen Alarmen; der Webhook bekommt keine. Die Sammelmeldung lässt sich in den Einstellungen abschalten.

Endpoint POST /alert-config/test feuert einen Dummy-Alert durch alle aktiven Kanäle und liefert ein Per-Channel-Ergebnis (status, HTTP-Code, Fehler, Versuche) zurück. Button direkt unter /app/settings/notifications. Use Cases: nach Slack-Channel-Wechsel, Bot-Token-Update oder Webhook-URL-Änderung sofort verifizieren, ohne auf einen echten Vorfall zu warten.