Das Standard-Hangfire-Dashboard ist komplett passiv. Es zeigt dir bereitwillig eine Wand fehlgeschlagener Jobs — sobald du daran denkst, es zu öffnen. Es meldet sich nie von selbst, weshalb Teams meistens genau dann merken, dass etwas nicht stimmt, wenn ein Kunde anruft und fragt, warum der nächtliche Report nie angekommen ist.
In der Praxis bedeutet "mit meinen Background-Jobs stimmt etwas nicht" fast immer einen von zwei klar unterscheidbaren Fehlerfällen, und die brauchen unterschiedliche Erkennung:
Der offensichtliche Fall: Ein Job-Typ fängt an, Exceptions zu werfen — eine nachgelagerte API hat ihren Vertrag geändert, ein Datenbank-Constraint lehnt plötzlich Zeilen ab, was auch immer. Eine Fehlerraten-Alert-Regel beobachtet genau das: Überschreiten die Fehler eines Job-Typs innerhalb eines Zeitfensters einen Schwellwert, feuert sie. Ein Cooldown verhindert, dass sie bei jedem einzelnen weiteren Fehler erneut feuert, sobald man schon Bescheid weiss, und sie löst sich automatisch auf, sobald die Rate wieder sinkt — kein manuelles "Alert schliessen" nötig.
Der tückischere Fall: Der Hangfire-Serverprozess lebt technisch, hat aber komplett aufgehört, Jobs abzuholen — keine Exceptions, keine Failed-Job-Liste, weil gar nichts mehr versucht wird. Ein reiner Job-Event-Stream kann das nicht erkennen, weil es keine Events gibt, die man anschauen könnte. Genau dafür gibt es eine Heartbeat-Timeout-Alert-Regel: Jeder Hangfire-Server meldet sich periodisch, und wenn ein Server sein Timeout überschritten hat, ist das der Alert — unabhängig davon, was die Job-Event-Historie zeigt.
Beide Regeltypen laufen über dieselben Notification-Kanäle: Slack (Incoming Webhook), Microsoft Teams (Incoming Webhook) oder E-Mail. Man richtet einen Kanal einmal pro Team/Ziel ein und hängt ihn dann an die Alert-Regeln, die ihn benachrichtigen sollen — eine Regel kann dabei mehr als einen Kanal gleichzeitig benachrichtigen (z. B. Slack und E-Mail bei etwas Dringendem).
Beide Alert-Regeltypen kommen mit sinnvollen Presets (z. B. 90 Sekunden Heartbeat-Timeout, gängige Fehlerraten-Zeitfenster), sodass man nicht standardmässig Rohzahlen eintippen muss — aber jeder Schwellwert (Cooldown, Fehleranzahl, Zeitfenster, Heartbeat-Timeout, für welchen Job-Typ die Regel gilt) ist pro Application im Dashboard editierbar. Einen Notification-Kanal anzulegen und ihn Ende-zu-Ende zu testen (eine echte Testnachricht, keine simulierte) dauert unter einer Minute.
Erst noch das Webhook selbst einrichten? Siehe Slack Incoming Webhook einrichten oder Microsoft-Teams-Webhook einrichten.
Siehe auch: warum Job-Historie überhaupt verschwindet, und wie das skaliert, sobald mehr als eine Application überwacht wird.
Kostenlos für eine Application, keine Kreditkarte nötig.