Guide
One dashboard for every
background job you run
Hangfire's dashboard is excellent - for one application. The problem starts at the tenth application, when answering 'which jobs failed last night?' means opening ten browser tabs and hoping the retention window hasn't rolled over.
Why this gets painful
Nothing here is a flaw in Hangfire. It's a consequence of the dashboard being scoped to the storage of a single application - which is the right design for a single application.
| Today | With an aggregation layer |
|---|---|
| One dashboard per service, each behind its own URL and auth | One dashboard for the whole estate, one login |
| History bounded by each app's storage retention | Execution history persisted centrally in PostgreSQL |
| Logs only in each application's own sink | Real-time log streaming attached to each execution |
| Failures noticed when somebody complains | Alerts on failure and timeout across every service |
| No way to compare job health across services | Success rate, duration and throughput per job |
| Teams on Quartz.NET are invisible to teams on Hangfire | Both schedulers reporting into the same view |
The setup
Add one package per application and register it. Hangfire carries on scheduling and executing exactly as before - Milvaion only observes.
builder.Services.AddMilvaionHangfireIntegration(
builder.Configuration);
builder.Services.AddHangfire((sp, config) =>
config.UseMilvaion(sp));builder.Services.AddMilvaionQuartzIntegration(
builder.Configuration);
builder.Services.AddQuartz(q =>
q.UseMilvaion(builder.Services));Each application also needs RabbitMQ and Redis connection settings under a Worker section in configuration, plus an ExternalScheduler source name so the dashboard knows where the jobs came from. The full configuration reference is in the integration guide.
What shows up in the dashboard
External jobs are first-class in the views and metrics, but read-mostly in the actions - because the originating scheduler still owns them.
Included
- Job list with source scheduler indicated
- Execution history with status, duration and result
- Exception details on failure
- Real-time logs published from inside the job
- Success rate, average duration and executions per minute
- Failure and timeout alerting
Deliberately disabled
- Triggering an external job manually
- Deleting an external job
- Cancelling a running external occurrence
- Editing schedule, job data or worker
- Toggling active status or auto-disable
Frequently asked questions
Can one Hangfire dashboard show jobs from multiple applications?+
Only if those applications share a single Hangfire storage, which couples them together and is rarely acceptable across service boundaries. In practice each service ends up with its own dashboard behind its own URL and its own authentication. Milvaion solves this from the other direction: each application reports its job activity outward, and the aggregation happens in one place.
Do I have to move off Hangfire to get this?+
No. Hangfire keeps scheduling and executing everything. Milvaion registers a Hangfire filter that reports registrations and executions over RabbitMQ, so the jobs show up in a shared dashboard flagged as external. Your job code and triggers are untouched.
Does this work for Quartz.NET too?+
Yes. There is an equivalent package for Quartz.NET that registers scheduler and job listeners. Services using Hangfire and services using Quartz.NET appear side by side in the same dashboard, which is usually the point when different teams have picked different schedulers.
How long is execution history kept?+
Milvaion persists occurrences in PostgreSQL, so history is not bound by your Hangfire storage retention settings. A built-in maintenance worker handles cleanup and archival on a schedule you configure.
Can I trigger or delete Hangfire jobs from the Milvaion dashboard?+
No, and deliberately so. External jobs are read-mostly: trigger, delete and cancel are disabled, and schedule fields are read-only, because Hangfire still owns them. You can edit Milvaion-side metadata such as display name, description, tags and zombie timeout.
What does it cost?+
Milvaion is open source under Apache 2.0, dashboard included. The operational cost is the infrastructure it needs: PostgreSQL, Redis and RabbitMQ.
Try it without touching your applications
Pre-built sample Hangfire and Quartz.NET worker images will report into a local Milvaion stack, so you can see what the aggregated dashboard looks like before wiring anything into your own services.