Ein neues Kundenprojekt in unter 10 Minuten ans Hangfire-Monitoring anbinden

6. August 2026 · QueueHawk

Ein neues Kundenprojekt zu QueueHawk hinzuzufügen braucht keinen zweiten Account, keinen zweiten Login und keine Änderung daran, wie Hangfire bereits läuft. Hier die exakte Abfolge, von Anfang bis Ende.

1. Application anlegen

Im Dashboard eine neue Application unter dem bestehenden Tenant anlegen — benennt sie so, dass man das Kundenprojekt wiedererkennt (z. B. "Acme Corp — Production"). Das stellt einen API-Key aus, einmalig angezeigt, mit Präfix qh_live_. Die Applications-Anzahl jedes Plans wird serverseitig durchgesetzt, nicht nur in der UI — am Plan-Limit gibt es also einen klaren Upgrade-Hinweis statt eines stillen Fehlschlags.

2. Agent im Kundenprojekt installieren

Das QueueHawk.Agent-NuGet-Package zum Hangfire-Host des Kunden hinzufügen und neben dem bestehenden Hangfire-Setup registrieren:

dotnet add package QueueHawk.Agent

builder.Services.AddQueueHawk(options =>
{
    options.ApiKey = builder.Configuration["QueueHawk:ApiKey"];
    options.Environment = "Production"; // Freitext, kein festes Format
});

Den API-Key als Secret speichern (Umgebungsvariable, Secrets-Manager, was das Kundenprojekt bereits nutzt) statt ihn zu committen. Environment ist ein Freitext-Label — muss zu nichts Bestimmtem passen, es erscheint nur im Dashboard, um Umgebungen auseinanderzuhalten, falls Staging und Production separat überwacht werden.

3. Deployen, dann Events prüfen

Kein separater "Verbindung testen"-Schritt nötig — sobald das Kundenprojekt mit laufendem Agent deployed ist, erscheint die nächste Hangfire-Job-Ausführung innerhalb von Sekunden in der Job-Liste der Application. Erscheint nach ein paar Minuten nichts, sind die zwei häufigsten Ursachen ein API-Key, der von der Konfiguration nicht tatsächlich übernommen wurde, oder ausgehendes HTTPS, das am Netzwerk-Egress des Kunden blockiert ist — der Agent ist push-only, er muss QueueHawks Ingestion-Endpoint erreichen können, nichts muss zurück erreichbar sein.

4. Alerts setzen (oder den Default machen lassen)

Für jede neue Application wird automatisch eine Heartbeat-Timeout-Alert-Regel angelegt — Zero-Config-Grundschutz gegen "der Worker ist lautlos stehengeblieben". Von dort aus eine Fehlerraten-Regel ergänzen, falls das Kundenprojekt Jobs hat, bei denen Fehlschläge wichtig genug sind, um jemanden zu alarmieren, und wählen, welcher Notification-Kanal — Slack, Teams, Webhook oder E-Mail — ihn erhalten soll. Kanäle werden Tenant-weit geteilt — wer bereits einen Slack-Kanal für ein anderes Kundenprojekt eingerichtet hat, kann ihn hier wiederverwenden statt einen neuen anzulegen.

Das ist der komplette Ablauf — kein separates Dashboard zum Merken, kein separater Login für dieses Kundenprojekt, es erscheint einfach als eine weitere Zeile neben jeder anderen bereits überwachten Application. Siehe auch: warum eine App-übergreifende Sicht ab dem zweiten oder dritten Kundenprojekt zählt.