Wenn du schon einmal eine Hangfire-App neu deployed und danach nach den Fehlern von gestern gesucht hast, nur um festzustellen, dass das Dashboard sie nicht mehr kennt — das ist keine Fehlkonfiguration. Genau so ist es gedacht: Das Hangfire-Dashboard ist eine Live-Ansicht des aktuellen Storage-Zustands, kein Audit-Log.
Alles, was das Hangfire-Dashboard anzeigt — Enqueued, Processing, Succeeded, Failed — kommt direkt aus deinem Hangfire-Storage (SQL Server, PostgreSQL, Redis, was auch immer konfiguriert ist), im Moment, in dem du die Seite lädst. Es ist kein separates Log, das sich über die Zeit ansammelt, sondern ein Fenster auf die gerade existierenden Zeilen. Sobald eine Zeile aus dem Storage verschwunden ist, hat das Dashboard nichts mehr dazu zu zeigen.
Hangfire bringt einen Hintergrund-Sweep mit, der kontinuierlich läuft und erfolgreiche wie fehlgeschlagene Job-Datensätze entfernt, sobald sie ein Retention-Fenster überschreiten — standardmässig in der Grössenordnung eines Tages, wobei das genaue Verhalten je nach Storage-Provider und Version variieren kann und konfigurierbar ist. Das läuft unabhängig davon, ob gerade deployed wurde — Hangfire hält damit einfach seinen eigenen Storage schlank. Ein sinnvoller Standard, um den Storage klein zu halten — er bedeutet nur, dass "Job-Historie" von Anfang an nie als dauerhaft gedacht war.
Falls dein Hangfire-Storage-Backend Prozess-Neustarts nicht übersteht (z. B. ein In-Memory-Provider für lokale Entwicklung oder einen schnellen Proof of Concept), räumt ein Redeploy oder App-Pool-Recycle nicht nur alte Jobs nach Zeitplan auf — er löscht sie alle auf einmal, erfolgreiche, fehlgeschlagene und wartende gleichermassen, in dem Moment, in dem der Prozess leer wieder hochkommt.
Bei einem einzelnen kleinen Projekt merkt man das selten — man sieht einen Fehler, behebt ihn, macht weiter. Bei einer Agentur, die Hangfire über ein Dutzend Kundenprojekte betreibt, sieht das anders aus: Ein Kunde fragt, warum sein nächtlicher Import vor drei Wochen fehlgeschlagen ist, und es gibt keine Antwort, weil der Datensatz, der das erklärt hätte, längst gelöscht wurde, bevor jemand überhaupt nachschauen wollte. Die Lücke ist unsichtbar — bis genau zu dem Moment, in dem man sie nicht gebrauchen kann.
Zwei Optionen, die sich nicht ausschliessen:
QueueHawk.Agent streamt jede Job-State-Änderung sofort per HTTPS nach aussen, sodass die Historie unabhängig davon existiert, welches Retention-Fenster oder Storage-Backend Hangfire selbst gerade nutzt — 7 bis 365 Tage je nach Plan, und sie übersteht Redeploys, Neustarts und Storage-Migrationen gleichermassen, weil sie nie in derselben Datenbank lag, die Hangfire aufräumt.Siehe auch: wie QueueHawk sich generell zum eingebauten Hangfire-Dashboard verhält, und was sich ändert, sobald das über mehr als ein Kundenprojekt läuft.
Kostenlos für eine Application, keine Kreditkarte nötig.