Hangfire-Monitoring, kein generisches Cron-Monitoring

Viele "Hangfire-Monitoring"-Tools funktionieren, indem sie aus einem Job heraus eine URL pingen und darauf warten, ob der Ping planmässig ankommt — dieselbe Technik wie für jeden Cron-Job, in jeder Sprache. Das sagt dir, dass ein Job gelaufen ist. Es sagt dir nicht, warum er fehlgeschlagen ist, wie lange die Queue-Wartezeit war, oder ob der ausgelöste State-Wechsel zu einem Retry gehörte. QueueHawk liest den tatsächlichen Job-Lifecycle, den Hangfire erzeugt.

Wie die Integration tatsächlich funktioniert

QueueHawk.Agent hookt in Hangfires eigene State-Change-Pipeline (IElectStateFilter/IApplyStateFilter). Bei jedem Job-Übergang — Enqueued → Processing → Succeeded/Failed, inklusive Retries — erfasst er Job-ID, Methode, Queue-Name, alten/neuen State und, bei einem Fehler, Exception-Typ, Meldung und Stacktrace. Failed-States werden über OnStateElection erfasst, bevor Hangfires Retry-Mechanismus sie überschreiben kann — ein Detail, das zählt, denn eine naive Integration, die nur den finalen State beobachtet, würde jeden vorübergehenden Fehler verpassen, der bei einem Retry doch noch erfolgreich war.

Erfasste Events landen in einem In-Memory-Ring-Buffer und werden per Hintergrunddienst in kleinen Batches über HTTPS verschickt, standardmässig alle 5 Sekunden. Ein separater Heartbeat alle 30 Sekunden meldet, dass jeder Hangfire-Server-Prozess noch lebt — der einzig verlässliche Weg, einen Worker zu erkennen, der zwar technisch läuft, aber lautlos aufgehört hat, Jobs zu verarbeiten — ein Fehlerbild, das kein Job-Event-Feed allein erkennen kann.

Storage-agnostisch, per Design

Der Agent fasst dein Hangfire-Storage nie direkt an — er funktioniert identisch, egal ob du SQL Server-, PostgreSQL- oder Redis-Storage nutzt. Nichts muss pro Backend anders konfiguriert werden, und es braucht keinen Lesezugriff auf deine Datenbank.

Was du über das eingebaute Dashboard hinaus bekommst

Hangfires eigenes Dashboard ist auf eine Storage-Instanz beschränkt, setzt seine Historie standardmässig bei Redeploy/Neustart zurück und meldet sich nie von selbst. QueueHawk ergänzt persistente Historie (7–365 Tage je nach Plan), eine einzige Sicht über alle Applications und Alert-Regeln (Fehlerrate, Heartbeat-Timeout), die Slack, Teams, Webhook oder E-Mail erreichen. Vollständiger Vergleich: QueueHawk vs. das Hangfire-Dashboard.

dotnet add package QueueHawk.Agent

builder.Services.AddHangfire(config =>
    config.UseSqlServerStorage(connectionString)); // jedes Hangfire-Storage funktioniert
builder.Services.AddHangfireServer();

// QueueHawk-Integration — eine Zeile
builder.Services.AddQueueHawk(options =>
{
    options.ApiKey = builder.Configuration["QueueHawk:ApiKey"];
    options.Environment = "Production";
});

Siehe auch: Slack-, Teams- oder E-Mail-Alerts, wenn ein Job fehlschlägt, und warum Job-Historie überhaupt nach jedem Deploy verschwindet.