One dashboard for every Hangfire instance across every client project and environment — with persistent history and real alerts, so you find out before your client does.
Works with the Hangfire storage and alert channels you already use
It's great for one app, on one day. Agencies running Hangfire across multiple client projects hit the same four walls.
Every client project means another tab, another login, another dashboard to remember to check.
Redeploy or restart, and yesterday's failures are gone — no trail to show a client what actually happened.
A job can quietly stop processing for days. Usually you find out when the client calls.
Is this job type getting slower or failing more often? Hangfire's dashboard can't tell you.
A lightweight NuGet package, no infrastructure changes, running alongside the Hangfire setup you already have.
Add the QueueHawk.Agent NuGet package to your Hangfire host and register it — a few lines, under 10 minutes.
Job events and heartbeats are sent out to QueueHawk. Nothing ever connects back in.
Every application, every environment, in one dashboard — with Slack, Teams, webhook, or email alerts when something's wrong.
QueueHawk.Agent hooks into Hangfire's own state-change pipeline (IElectStateFilter/IApplyStateFilter) — the same extension points Hangfire itself uses internally. On every job transition (Enqueued → Processing → Succeeded/Failed, including retries), it captures the job ID, method, queue name, old/new state, and — on failure — the exception type, message and stack trace.
Captured events land in an in-memory buffer and are sent in small batches over HTTPS by a background service, every 5 seconds by default. A separate heartbeat every 30 seconds reports that each Hangfire server process is still alive — the only reliable way to catch "the server is up but has silently stopped processing anything."
It never touches your Hangfire storage directly, so it works the same whether you're on SQL Server, PostgreSQL, or Redis storage. Job arguments/payloads are never sent unless you explicitly opt in (see Security below), and any internal error is caught and logged — never thrown into your job pipeline.
Works on all current .NET versions.
View QueueHawk.Agent on NuGet.orgdotnet add package QueueHawk.Agentbuilder.Services.AddHangfire(config =>
config.UseSqlServerStorage(connectionString)); // any Hangfire storage works
builder.Services.AddHangfireServer();
// QueueHawk integration — one line
builder.Services.AddQueueHawk(options =>
{
options.ApiKey = builder.Configuration["QueueHawk:ApiKey"];
options.Environment = "Production"; // free text, e.g. also the client name
});Priced the way agencies actually think about their work — per client project, not per event or job run. Every application includes unlimited job types, so adding another recurring job never changes your bill.
Try it on one project, no card required.
For a single project that matters.
For agencies running several client projects.
For every client project you run.
Not a generic "EU region" of a foreign cloud — infrastructure, database, and application all run on servers in Switzerland. Why that matters →
Every account's data is isolated end-to-end, enforced at the database layer, not just the UI.
No inbound connection to your infrastructure, ever — nothing to open in your firewall.
Job metadata and error details only — never your job payloads or business data.
The things agencies usually ask before rolling QueueHawk out across client projects.
One Hangfire-connected application or instance — a client project, a service, an environment. Plans scale by how many applications you monitor, not by event volume or job count, which is how agencies actually think about their work.
Because it punishes exactly the customers we're built for. An application with 40 job types costs the same as one with 3 — you're never billed extra for adding another recurring job to a project you already monitor. See the full breakdown and a calculator for how that compares to per-job pricing at different scales.
It depends on your plan: 7 days on Free, 14 days on Starter, 180 days on Team, and 365 days on Agency. History survives redeploys and restarts — unlike Hangfire's own dashboard.
Job metadata: job type, queue, state transitions, timing, and — on failure — the exception type, message and stack trace. Job arguments and payloads are never sent unless you explicitly opt in.
The agent targets all current .NET versions and works identically whether your Hangfire storage is SQL Server, PostgreSQL, or Redis — it hooks into Hangfire's own state-change pipeline rather than reading storage directly.
Yes — upgrade, downgrade, or cancel anytime from the billing page in your dashboard. No contracts, no sales calls.
Yes. Tenant isolation is enforced at the database layer for every query, not just hidden in the UI — one account can never see another's applications, job data, or alerts.
QueueHawk's own background jobs run on Hangfire — and we monitor them with QueueHawk, every day. If it breaks, we notice the same way you would.