Benachrichtigungen & Abonnements

SLAtus versendet Benachrichtigungen über Statusänderungen, Incidents, Wartungen und SLA-Reports. Es gibt vier unabhängige Kanäle: E-Mail, Webhook, SMS und Web-Push.

Wer E-Mails erhält

Die Site-Einstellung Abo-Modus steuert die E-Mail-Empfänger (settings.subscriptionMode):

Modus	Empfänger
none	Keine E-Mail-Abonnements. Öffentliche Anmeldung ist deaktiviert.
users	Alle Benutzerkonten, unabhängig von der Rolle
users_public	Alle Benutzerkonten und alle bestätigten Abonnenten

Vom Admin verwaltete Abonnenten (unter /admin/subscribers) gelten als bestätigt.

Öffentliche Anmeldung (Double Opt-in)

Nur verfügbar, wenn der Modus users_public ist und ein E-Mail-Provider eingerichtet ist. Sonst zeigt der Dialog, dass E-Mail-Abonnements deaktiviert sind.

1. Ein Besucher gibt auf der Statusseite im Dialog eine E-Mail-Adresse ein, optional mit Namen (höchstens 200 Zeichen).
2. Ist die Adresse bereits bestätigt, zeigt der Dialog, dass sie schon abonniert ist, und es wird keine E-Mail gesendet.
3. Andernfalls wird eine Bestätigungsmail mit Token-Link versendet (double_optin). Diese Mail geht nur per E-Mail an die angegebene Adresse, nie über Webhook, SMS oder Push.
4. Der Link öffnet eine Seite mit einem Bestätigen-Button. Erst der Klick bestätigt die Adresse. Das bloße Öffnen des Links ändert nichts.
5. Der Link ist 7 Tage gültig. Abgelaufene oder ungültige Links zeigen eine klare Meldung. Es wird nichts bestätigt.

Bestätigte Tokens bleiben bis zur täglichen Bereinigung nach 30 Tagen erhalten. Wiederholte Klicks liefern daher weiterhin die Meldung „bereits angemeldet“.

Fehler der öffentlichen Formulare liefern die Server Actions als Codes (lib/validations/public-form-errors.ts). Die Formulare zeigen sie in der eingestellten Sprache an.

Abmeldung

Die Abmeldeseite versendet eine Bestätigungsmail mit Token-Link, aber nur an bestätigte Adressen. Die Antwort auf der Seite ist für jede Adresse gleich. Der zweite Schritt ist wieder ein Button-Klick. Gelöscht wird nur mit gültigem Token, der Link ist 7 Tage gültig. Unbekannte und abgelaufene Tokens werden unterschiedlich gemeldet, und die Seite bietet das Formular erneut an.

Datenauskunft (DSGVO Art. 15 und 20)

Abonnenten können ihre gespeicherten Daten unter /subscribe/my-data anfordern. Der Ablauf entspricht der Abmeldung: Anfrage per E-Mail, Bestätigung über Link und Button. Der Export enthält E-Mail-Adresse, Name, Quelle, Zeitpunkte für Bestätigung und Anlage und kann als JSON heruntergeladen werden. Der Token ist 7 Tage gültig. Die Seite zeigt die Daten nur an, Löschen geht über die Abmeldung.

Rate-Limit der öffentlichen Formulare

Abonnieren, Abmelde-Link anfordern und Datenauskunft anfordern sind gedrosselt (allowPublicFormRequest in lib/auth/public-form-throttle.ts). Es gibt zwei Zähler in auth_throttle:

Zähler	Standard	Sperre
Je Client-IP, über alle drei Formulare	10 Anfragen in 60 Minuten	60 Minuten
Je Adresse und Formular	1 Anfrage in 10 Minuten	10 Minuten
Sammel-Zähler unknown, wenn keine Client-IP erkennbar ist	100 Anfragen in 60 Minuten	60 Minuten

• Jede Anfrage zählt, nicht nur fehlerhafte. Die letzte erlaubte geht noch durch, danach ist bis zum Ende der Sperre gesperrt.
• Eine gedrosselte Anfrage antwortet wie eine erfolgreiche ({ ok: true }), es wird aber keine Mail versendet. Bei einer bestätigten Adresse entfällt dann auch der Hinweis, dass sie schon abonniert ist.
• Der Adress-Zähler speichert keine Adresse, sondern einen HMAC-SHA-256 mit SESSION_SECRET.
• Die Werte sind über PUBLIC_FORM_RATELIMIT_* konfigurierbar (siehe Deployment, Migrationen & CI). Fällt der Speicher aus, laufen die Formulare ungedrosselt weiter.

Steuerung je Komponente

Jede Komponente hat folgende Einstellungen, bearbeitbar unter Services → (Service) in der Karte Notifications:

• Send notifications for this service (notifications_enabled): ein Hauptschalter. Sind alle betroffenen Komponenten stummgeschaltet, wird auf keinem Kanal gesendet.
• Notify via (notify_mail_enabled, notify_sms_enabled, notify_webhook_enabled, notify_push_enabled): Jeder Kanal kann für eine Komponente einzeln gesperrt werden.
• Additional notification email address (notification_email): eine zusätzliche Adresse, die Mails zu dieser Komponente erhält, sofern der Mail-Kanal für sie aktiv ist. Sie wird als BCC ergänzt und dedupliziert.

Versände mit explizit angegebenen Empfängern, zum Beispiel Double-Opt-in-Mails, erhalten die zusätzliche Adresse nicht.

Kanäle

Kanal	Einrichtung	Hinweise
E-Mail	Settings → Mail/SMS/Push/Webhook, Karte Email-Setup (SMTP oder Resend). Provider none deaktiviert E-Mail.	Templates je Event-Typ sind unter Notifications editierbar, mit Platzhaltern wie {{siteName}}. Ein gemeinsamer Mail-Abschluss mit Abmeldelink wird angehängt.
Webhook	Settings → Mail/SMS/Push/Webhook, Karte Webhooks. Nur Admins (ROLES_CAN_MANAGE_NOTIFICATIONS).	Ziel-URL, erzeugtes Secret (verschlüsselt, rotierbar), optionaler Event-Filter, Zieltyp generic, slack, teams oder discord. Signatur mit HMAC-SHA256 im Header X-SLAtus-Signature. 3 Versuche mit 10 Sekunden Timeout.
SMS	Settings → Mail/SMS/Push/Webhook, Provider Twilio	Vom Admin verwaltete Empfänger. Keine Selbstanmeldung für Besucher, bewusst wegen Kosten, Missbrauch und Datenschutz. Nachricht ist auf 300 Zeichen begrenzt.
Web-Push	Settings → Mail/SMS/Push/Webhook, VAPID-Schlüssel in der Admin-Oberfläche erzeugen	Besucher aktivieren Push über die Glocke in der Kopfzeile, auf dem Smartphone in einem Menü. Die Glocke erscheint erst, wenn Schlüssel erzeugt sind. Der VAPID-Subject muss mit mailto: oder https: beginnen.

Jeder Event-Typ hat eine Template-Zeile mit einem Aktivierungs-Flag je Kanal. Ein Kanal ohne aktivierte Zeile sendet nicht. Fehlt die Zeile für einen neuen Event-Typ, legt der Worker sie beim nächsten Start mit allen Kanälen aktiv an (ensureNotificationTemplateRows). Nur zwischen Migration und Worker-Neustart muss man einen neuen Typ unter Notifications von Hand einschalten.

Mail-only-Typen (MAIL_ONLY_EVENT_TYPES, derzeit double_optin) gehen ausschließlich per E-Mail. Webhook, SMS und Push überspringen sie unabhängig von den Flags. Serverseitig lassen sie sich weder als Event-Filter von Webhook, SMS oder Push noch als Kanal-Flag setzen.

Zustellung überwachen

• /admin/notification-events listet die versendeten E-Mail-Events mit Status pending, processing, sent oder failed. Bei fehlgeschlagenen Events gibt es Resend. Wurde ein Event nur an einen Teil der Empfänger zugestellt, zeigt die Liste „x / y“ Empfänger, und der Button heißt Resend remaining. Er beliefert nur die übrigen Empfänger.
• /admin/notifications enthält die Templates und Kanal-Schalter.
• Webhook, SMS und Push haben eigene Zustelltabellen. Jeder Webhook, jeder SMS-Empfänger und jedes Push-Abo zeigt in den Einstellungen seinen letzten Zustellstatus.