"Dashboard Authorization obsolete" — 15,000 forum views. "Dashboard not visible on azure websites" — 9,000 views. The same two complaints have been the top Hangfire production-deployment thread for years, and the underlying issue is older than the threads: the dashboard is wide-open by default, the official authorization story has changed twice, and every team deploying Hangfire eventually asks the same question — how do I let the right people look at job state without exposing /hangfire to the public internet?
By default, Hangfire's dashboard endpoint accepts every request when running on localhost, and on most setups that's it — there's no built-in authentication. The moment you deploy to a server where /hangfire is reachable from the internet (or from an internal network that's not locked down to your team), you've exposed your job state, queue contents, and stack traces to anyone who can reach the URL. Stack traces from failed jobs often include method names, file paths, and partial arguments — not something you want on a public endpoint.
Hangfire's own dashboard authorization has gone through three stages, and the documentation hasn't always kept up:
OwinMiddleware or ASP.NET Core middleware to lock it down.IDashboardAuthorizationFilter was introduced, with a default implementation that allowed all requests on localhost and denied all on remote connections. Better, but the "deny all remote" default meant the dashboard was unreachable in containerized, load-balanced, or reverse-proxy setups — every request looked "remote."IDashboardAuthorizationFilter still exists, but the default DashboardOptions.Authorization array is empty in many setups, and a lot of community guidance still points at the older middleware-based pattern. The result is that most teams either copy a stale Stack Overflow answer or just leave the dashboard open.A common workaround is to put the dashboard behind a reverse proxy that allows only certain IPs — a network ACL on /hangfire. This works until someone's IP changes, or a developer needs access from a new location, or a stakeholder asks for a view into "their" jobs and doesn't have a corporate IP. The ACL is also easy to forget during a redeploy or a move to a new hosting setup. It's not that reverse-proxy allow-listing is wrong — it's that it solves access control at the wrong layer for anything beyond a single-team internal tool.
Behind every "Dashboard Authorization" forum thread is the same underlying need: how do I give specific people a view into specific Hangfire instances, safely, without exposing everything to everyone? That's a multi-tenant authorization problem, not a network ACL problem. Specifically:
The clean split is to stop trying to lock down the per-instance dashboard and instead give people a separate, authenticated view that reads from all your Hangfire instances. Each instance streams state changes out over HTTPS as they happen — no inbound dashboard endpoint to expose — and a central service with real authentication (JWT, SSO, whatever your team uses) serves the consolidated view.
That's what QueueHawk is: a hosted dashboard over Hangfire data, with per-tenant auth, multi-instance aggregation, and no inbound dashboard endpoint on your Hangfire process at all. QueueHawk.Agent only makes outbound HTTPS calls — there's no port to open, no reverse proxy to configure, no ACL to maintain. Each user sees only the applications their tenant owns; clients don't see other clients' jobs; on-call engineers see everything. The Hangfire process itself never accepts a dashboard request again.
/hangfire exposes job state and stack traces to anyone who can reach it.See also: keeping Hangfire job history longer than 24 hours (the other thing the built-in dashboard can't do), monitoring Hangfire across multiple client apps (why this gets worse per instance), and how QueueHawk compares to the built-in Hangfire dashboard overall.
Free for one application, no card required.