Hangfire monitoring, not generic cron monitoring

A lot of "Hangfire monitoring" tools work by pinging a URL from inside a job and waiting to see if the ping arrives on schedule — the same technique used for any cron job, in any language. That tells you a job ran. It doesn't tell you why it failed, how long the queue took to pick it up, or whether the state transition that fired belonged to a retry. QueueHawk reads the actual job lifecycle Hangfire produces.

How the integration actually works

QueueHawk.Agent hooks into Hangfire's own state-change pipeline (IElectStateFilter/IApplyStateFilter). 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. Failed states are captured via OnStateElection, before Hangfire's retry mechanism can overwrite them — a detail that matters, because a naive integration watching only the final state would miss every transient failure that eventually succeeded on retry.

Captured events land in an in-memory ring 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 a worker that's technically running but has silently stopped picking up jobs, a failure mode no job-event feed alone can detect.

Storage-agnostic, by design

The agent never touches your Hangfire storage directly — it works identically whether you're running SQL Server, PostgreSQL, or Redis storage. There's nothing to configure differently per backend, and no read access to grant against your database.

What you get beyond the built-in dashboard

Hangfire's own dashboard is scoped to a single storage instance, resets its history on redeploy/restart by default, and never pushes anything to you. QueueHawk adds persistent history (7–365 days depending on plan), a single view across every application, and alert rules (error rate, heartbeat timeout) that reach Slack, Teams, webhook, or email. Full comparison: QueueHawk vs. the Hangfire Dashboard.

dotnet add package QueueHawk.Agent

builder.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";
});

See also: getting Slack, Teams, or email alerts when a job fails, and why job history disappears after every deploy in the first place.