Honest positioning up front: QueueHawk doesn't monitor arbitrary .NET code or every scheduler out there — it's built for one thing, Hangfire, which is the de facto standard for background job processing in .NET.
If your .NET application processes work outside the request/response cycle — emails, report generation, payment reconciliation, data syncs — there's a good chance it's running on Hangfire already. Hangfire's own dashboard is excellent for a quick look at one running instance. It wasn't designed to be your team's monitoring system, and QueueHawk is.
Some monitoring tools advertise support for half a dozen schedulers across as many languages, each integration necessarily shallow. QueueHawk's agent hooks directly into Hangfire's own state-change pipeline (IElectStateFilter/IApplyStateFilter) — depth that's only possible because it targets exactly one framework. Quartz.NET support is on the roadmap as a separate, equally deep integration when it ships, not a generic wrapper bolted on for a checkbox.
Every Hangfire-connected .NET application shows up as its own row, in one place — not one /hangfire route per project.
Independent of whatever Hangfire storage you configured, kept for 7–365 days depending on plan.
Slack, Microsoft Teams, webhook, or email — the moment an error-rate threshold or heartbeat timeout is crossed.
The agent sends events out over HTTPS. Nothing ever connects back in to your infrastructure.
One NuGet package, one line of registration, alongside the Hangfire setup you already have — works identically on net8.0, net9.0, and net10.0.
dotnet add package QueueHawk.Agentbuilder.Services.AddQueueHawk(options =>
{
options.ApiKey = builder.Configuration["QueueHawk:ApiKey"];
options.Environment = "Production";
});Full technical detail on the Hangfire integration itself: Hangfire monitoring. Full feature comparison: QueueHawk vs. the Hangfire Dashboard.