Ein Dashboard für jede Hangfire-Instanz über alle Kundenprojekte und Umgebungen hinweg — mit dauerhafter Historie und echten Alerts, damit du es merkst, bevor dein Kunde anruft.
Funktioniert mit dem Hangfire-Storage und den Alert-Kanälen, die du schon nutzt
Es ist gut für eine App, an einem Tag. Agenturen mit mehreren Kundenprojekten auf Hangfire stossen immer an dieselben vier Grenzen.
Jedes Kundenprojekt bedeutet einen weiteren Tab, einen weiteren Login, ein weiteres Dashboard zum Nachschauen.
Nach einem Redeploy oder Neustart sind gestrige Fehler weg — keine Spur, um einem Kunden zu zeigen, was passiert ist.
Ein Job kann tagelang leise aufhören zu verarbeiten. Meistens merkt man es, wenn der Kunde anruft.
Wird dieser Job-Typ langsamer oder fehleranfälliger? Hangfires Dashboard kann es dir nicht sagen.
Ein schlankes NuGet-Package, keine Infrastruktur-Änderungen, läuft neben dem Hangfire-Setup, das du schon hast.
QueueHawk.Agent NuGet-Package zu deinem Hangfire-Host hinzufügen und registrieren — ein paar Zeilen, unter 10 Minuten.
Job-Events und Heartbeats werden an QueueHawk gesendet. Nie baut etwas eine Verbindung zurück auf.
Jede Application, jede Umgebung, in einem Dashboard — mit Slack-, Teams-, Webhook- oder E-Mail-Alerts, wenn etwas nicht stimmt.
QueueHawk.Agent hängt sich in Hangfires eigene State-Change-Pipeline ein (IElectStateFilter/IApplyStateFilter) — dieselben Erweiterungspunkte, die Hangfire intern selbst nutzt. Bei jedem Job-Übergang (Enqueued → Processing → Succeeded/Failed, inkl. Retries) erfasst er Job-ID, Methode, Queue-Name, alten/neuen State und bei einem Fehler zusätzlich Exception-Typ, -Message und Stacktrace.
Erfasste Events landen in einem In-Memory-Puffer und werden von einem Hintergrunddienst in kleinen Batches per HTTPS gesendet, standardmässig alle 5 Sekunden. Ein separater Heartbeat alle 30 Sekunden meldet, dass jeder Hangfire-Serverprozess noch lebt — der einzige zuverlässige Weg zu erkennen, dass "der Server läuft, aber lautlos aufgehört hat, irgendetwas zu verarbeiten".
Er greift nie direkt auf deinen Hangfire-Speicher zu, funktioniert also gleich, egal ob SQL Server, PostgreSQL oder Redis als Storage läuft. Job-Argumente/Payloads werden nie gesendet, ausser du aktivierst das explizit (siehe Sicherheit unten), und jeder interne Fehler wird abgefangen und geloggt — nie in deine Job-Pipeline durchgereicht.
Funktioniert auf allen aktuellen .NET Versionen
QueueHawk.Agent auf NuGet.org ansehendotnet add package QueueHawk.Agentbuilder.Services.AddHangfire(config =>
config.UseSqlServerStorage(connectionString)); // jeder Hangfire-Storage funktioniert
builder.Services.AddHangfireServer();
// QueueHawk-Integration — eine Zeile
builder.Services.AddQueueHawk(options =>
{
options.ApiKey = builder.Configuration["QueueHawk:ApiKey"];
options.Environment = "Production"; // Freitext, z.B. auch der Kundenname
});Genau so bepreist, wie Agenturen wirklich denken — pro Kundenprojekt, nicht pro Event oder Job-Durchlauf. Jede Application enthält unbegrenzt viele Job-Typen — ein weiterer Recurring Job ändert nie die Rechnung.
Ausprobieren an einem Projekt, keine Kreditkarte nötig.
Für ein einzelnes Projekt, das wichtig ist.
Für Agenturen mit mehreren Kundenprojekten.
Für jedes Kundenprojekt, das du betreust.
Keine generische "EU-Region" eines ausländischen Cloud-Anbieters — Infrastruktur, Datenbank und Applikation laufen alle auf Servern in der Schweiz. Warum das zählt →
Die Daten jedes Accounts sind Ende-zu-Ende isoliert, auf Datenbankebene durchgesetzt, nicht nur im UI.
Keine eingehende Verbindung zu deiner Infrastruktur, nie — nichts, das du in deiner Firewall öffnen musst.
Nur Job-Metadaten und Fehlerdetails — nie deine Job-Payloads oder Geschäftsdaten.
Das, was Agenturen typischerweise fragen, bevor sie QueueHawk über ihre Kundenprojekte hinweg einführen.
Eine mit Hangfire verbundene Application oder Instanz — ein Kundenprojekt, ein Service, eine Umgebung. Pläne skalieren nach der Anzahl überwachter Applications, nicht nach Event-Volumen oder Job-Anzahl — so, wie Agenturen ihre Arbeit tatsächlich denken.
Weil das genau die Kunden bestraft, für die wir gebaut sind. Eine Application mit 40 Job-Typen kostet dasselbe wie eine mit 3 — ein weiterer Recurring Job in einem bereits überwachten Projekt wird nie extra berechnet. Siehe die vollständige Aufschlüsselung mit Rechner dazu, wie sich das bei unterschiedlichen Grössen gegen Pro-Job-Preise schlägt.
Abhängig vom Plan: 7 Tage bei Free, 14 Tage bei Starter, 180 Tage bei Team, 365 Tage bei Agency. Die Historie übersteht Redeploys und Neustarts — anders als Hangfires eigenes Dashboard.
Job-Metadaten: Job-Typ, Queue, State-Übergänge, Timing und bei einem Fehler zusätzlich Exception-Typ, -Message und Stacktrace. Job-Argumente und Payloads werden nie gesendet, ausser du aktivierst das explizit.
Der Agent funktioniert auf allen aktuellen .NET-Versionen und gleich, egal ob dein Hangfire-Storage SQL Server, PostgreSQL oder Redis ist — er hängt sich in Hangfires eigene State-Change-Pipeline ein, statt direkt auf den Storage zuzugreifen.
Ja — Upgrade, Downgrade oder Kündigung jederzeit über die Billing-Seite im Dashboard. Keine Verträge, keine Sales-Calls.
Ja. Mandantentrennung wird auf Datenbankebene für jede Abfrage durchgesetzt, nicht nur im UI versteckt — ein Account kann nie die Applications, Job-Daten oder Alerts eines anderen sehen.
QueueHawks eigene Background-Jobs laufen auf Hangfire — und wir überwachen sie mit QueueHawk, jeden Tag. Wenn etwas kaputtgeht, merken wir es genauso wie du.