Notification Rules

Eine Notification Rule prüft im Takt eine Bedingung und feuert eine Notification, wenn die Bedingung zutrifft. Zwei Muster decken ab, was die meisten Teams brauchen:

• Schwellenüberschreitung: „Alarm, wenn LCP bei p75 über 3.000 ms steigt."
• Relative Veränderung: „Alarm, wenn eine Metrik deutlich schlechter ist als im Fenster davor."

Dieser Guide zeigt beide. Die Engine dahinter ist dieselbe; nur die Bedingung sieht anders aus.

Setup-Zeit: etwa zehn Minuten pro Rule. Was du brauchst: Org-Mitgliedschaft mit Recht zum Anlegen von Rules (jede Rolle reicht für eigene Rules).

Wo Rules leben

Rules sind Organisationsressourcen. Jede Rule gehört dem User, der sie erstellt hat, aber andere Org-Mitglieder können sie sehen. Notifications gehen ans Delivery-Target der Rule; Default ist die E-Mail des Erstellers.

1. Preset wählen (oder leer starten)

Öffne in fastmon Notifications → Rules → New rule. Der erste Schritt zeigt Presets: übliche Rule-Formen mit sinnvollen Defaults:

• LCP regression: LCP p75 über der „Good"-Schwelle (2.500 ms) in den letzten 24 h
• CLS regression: CLS p75 über 0,1
• INP regression: INP p75 über 200 ms
• Traffic drop: Pageview-Zahl 50 % unter den vorherigen 24 h
• Error rate too high: mehr als 1 % der Pageviews mit JS-Fehler
• Page weight bloat: übertragene Bytes p75 über 3 MB in 7 Tagen

Nimm den, der am nächsten dran ist. Felder lassen sich danach beliebig anpassen. Passt nichts: Blank rule und weiter zu Schritt 3.

2. Delivery-Target wählen

Vier Target-Typen werden unterstützt:

• E-Mail: eine oder mehrere Adressen.
• Slack: native Incoming-Webhook-Integration.
• Discord: native Incoming-Webhook-Integration.
• Webhook: POST an eine URL mit JSON-Payload. Damit deckst du Teams, Mattermost, PagerDuty, Opsgenie oder jedes andere Tool mit Incoming-Webhook-URL ab.

Mehrere Targets pro Rule möglich. Jedes feuert auf dasselbe Event.

3. Bedingung definieren

Der zentrale Teil. Eine Rule besteht aus drei Bausteinen:

Was du misst

• Einen Scope: eine einzelne Site oder ein Site-Tag, um eine Gruppe von Sites mit einer Rule abzudecken (die Rule wertet jede Site im Tag einzeln aus).
• Eine Metrik (LCP, INP, CLS, FCP, TTFB, Fehlerrate, Pageviews, Visitors, …).
• Eine Aggregation (p50, p75, p95, count, avg, …). Die Metriken visitors und requests sind Zählungen und nehmen nur count.
• Für die Metrik visitors optional eine identity, die festlegt, welcher Identifier die Zählung trägt: stitch (Standard, am Edge abgeleitet, in jedem Modus) oder session (consent-gated). Gilt nur für visitors.
• Optional Filter (nur Mobile, ein bestimmtes URL-Pattern, eine Länderliste, …).

Wann du misst

• Ein Zeitfenster: 1 h, 6 h, 24 h, 7 Tage oder 30 Tage. Kürzere Fenster fangen schneller, sind aber lauter.
• Einen Takt stellst du nicht ein. Fastmon leitet den Auswertungstakt aus dem Fenster ab (ein Fünftel des Fensters, begrenzt auf 1 bis 15 Minuten): Eine 1-h-Rule wird also etwa alle 12 Minuten geprüft, eine 24-h-Rule alle 15.

Was eine Verletzung ist

Wähle eine der beiden Varianten:

• Über/unter Schwelle (absolut): fixe Zahl. „LCP p75 > 3.000 ms."
• Verändert sich vs. Vorfenster (relativ): verglichen mit dem Baseline-Fenster direkt vor dem aktuellen. „LCP p75 +20 %." Die Baseline ist standardmäßig genauso lang wie das Messfenster.

Jede Variante hat ihre eigene Stolperfalle:

• Absolute Schwellen sind stabil, bestrafen dich aber an dem Tag, an dem dir ein neues, großes Segment auf die Site kommt (mehr Slow-Network-Besucher → schlechtere Metrik → Alarm, gegen den du nichts machen kannst).
• Relative Schwellen sind empfindlich, aber auf Low-Volume-Sites laut. Ein schlechter Day-over-Day-Vergleich reicht zum Feuern. Auf traffic-schwachen Sites nimm lieber ein längeres Fenster (7 oder 30 Tage).

4. Rule im Trockenlauf testen

Bevor du speicherst, klicke Evaluate now. Damit läuft die Rule einmal gegen das aktuelle Fenster und sagt dir, ob sie feuern würde. Guter Sanity-Check für deine Schwelle: feuert sie bei jedem Test, ist die Schwelle zu eng.

API-Pendant: POST /notification-rules/{id}/evaluate.

5. Synthetischen Test schicken

Nach dem Speichern klicke Send test notification. Schickt eine Beispiel-Nachricht an alle Delivery-Targets, damit du bestätigen kannst, dass sie ankommen.

API-Pendant: POST /notification-rules/{id}/test.

6. History beobachten

Jede Rule hat einen History-Tab, der jede Auswertung listet, ob sie gefeuert hat und (wenn ja) wohin die Notification ging. Wenn ein Alarm mal nicht zu dem passt, was du im Dashboard siehst, ist die History der Audit-Trail.

Beispiel: LCP-Regression auf Production

Ziel: Alarm, wenn LCP bei p75 auf der Production-Site mehr als 20 % schlechter ist als die vorherigen 24 Stunden.

Auf einer traffic-schwachen Site wird der Day-over-Day-Vergleich zum Problem: Eine einzige langsame Nachtphase kann ein 24-h-p75 allein um 20 % verschieben. Bei dünnem Traffic erst das Fenster auf 7 Tage verbreitern, dann über die Schwelle nachdenken.

Häufige Stolperfallen

• Rules feuern beim Übergang, nicht bei jeder Auswertung. Eine Rule benachrichtigt, wenn ihre Bedingung von „nicht erfüllt" auf „erfüllt" kippt; solange die Regression anhält, bleibt sie still. Wer während eines längeren Vorfalls Erinnerungen will, setzt Re-notify after auf der Rule; dann sendet sie nach dieser Zeit erneut, falls die Bedingung weiterhin erfüllt ist.
• Auch in einem geplanten Wartungsfenster ist ein Alarm Lärm. Rule pausieren, oder per URL die betroffenen Pfade ausschließen.
• Per-Release-Bedingungen gibt es nicht. Rules vergleichen gegen Schwellen oder das Vorfenster, nicht gegen ein Release. Um einen konkreten Deploy zu beurteilen, nimm nach dem Alarm Releases vergleichen.

Verwandt

• Notification Rules API: programmatisches Anlegen.
• Releases-Konzept: Deploys taggen.
• Releases vergleichen: CI/CD verdrahten, um Deploys zu taggen.