Onboarding a new client project onto Hangfire monitoring in under 10 minutes

August 6, 2026 · QueueHawk

Adding a new client project to QueueHawk doesn't require a second account, a second login, or any change to how you already run Hangfire. Here's the exact sequence, start to finish.

1. Create the application

From the dashboard, add a new application under your existing tenant — name it whatever you'd recognize the client project by (e.g. "Acme Corp — Production"). This issues an API key, shown once, prefixed qh_live_. Every plan's application count is enforced server-side, not just in the UI, so you'll see a clear upgrade prompt rather than a silent failure if you're at your plan's limit.

2. Install the agent in the client's project

Add the QueueHawk.Agent NuGet package to the client's Hangfire host and register it alongside the existing Hangfire setup:

dotnet add package QueueHawk.Agent

builder.Services.AddQueueHawk(options =>
{
    options.ApiKey = builder.Configuration["QueueHawk:ApiKey"];
    options.Environment = "Production"; // free text, no fixed format
});

Store the API key as a secret (environment variable, secrets manager, whatever the client project already uses) rather than committing it. Environment is a free-text label — it doesn't have to match anything specific, it just shows up in the dashboard to tell environments apart if you're monitoring staging and production separately.

3. Deploy, then verify events are arriving

No separate "test connection" step needed — once the client project is deployed with the agent running, the next Hangfire job execution shows up in the application's job list within seconds. If nothing appears after a few minutes, the two most common causes are an API key that wasn't actually picked up by configuration, or outbound HTTPS being blocked at the client's network egress — the agent is push-only, so it needs to reach QueueHawk's ingestion endpoint, nothing needs to reach back in.

4. Set alerts (or let the default do it)

A heartbeat-timeout alert rule is created automatically for every new application — zero-config baseline protection against "the worker silently stopped." From there, add an error-rate rule if the client project has jobs where failures matter enough to page someone, and pick which notification channel(s) — Slack, Teams, webhook, or email — should receive it. Channels are shared across the whole tenant, so if you've already set up your team's Slack channel for another client project, reuse it here instead of creating a new one.

That's the whole flow — no separate dashboard to bookmark, no separate login for this client project, and it shows up as one more row next to every other application you're already monitoring. See also: why a single cross-app view matters once you're past two or three client projects.