Monitor Hangfire Recurring Jobs
Hangfire's recurring jobs run in-process against persistent storage (SQL Server, Redis, etc.) — failure modes include a stopped Hangfire server process, storage connectivity loss, or a job registration silently lost after a deploy.
Setup
Create an incoming monitor
Add a heartbeat monitor in Pingtastic matching the recurring job's interval.
Ping at the end of the job method
Add the ping call after the real work succeeds.
public class NightlyReportJob
{
public async Task RunAsync()
{
// ...existing job logic...
using var client = new HttpClient();
await client.GetAsync("https://ping.pingtastic.net/ping/nightly-report");
}
}Keep job registration on every startup
Confirm RecurringJob.AddOrUpdate() runs on every app startup, not just once manually — otherwise a redeploy that clears job storage can leave the schedule unregistered with no error.
Gotchas
- ⚠RecurringJob.AddOrUpdate() upserts by job ID — rename the job ID between deploys without realizing it, and you end up with two recurring jobs (the old one still firing, a new one also registered) rather than a clean rename.
- ⚠If the Hangfire server process itself isn't running (common after a deploy that doesn't restart it alongside the web app), jobs queue up in storage but never execute — no ping fires, correctly triggering a missed-check-in alert.
Questions
Does this work with Hangfire's dashboard alerting?
Hangfire's dashboard shows job history and failures within the app, but doesn't alert you proactively or catch the case where the Hangfire server process itself isn't running at all — a heartbeat ping covers that gap.
What about Quartz.NET instead of Hangfire?
The same pattern — ping at the end of the job's Execute method — applies to Quartz.NET jobs too; the scheduling library differs but the monitoring approach doesn't.
Start monitoring your .NET hangfire
Set up your first monitor in under five minutes.
Get started — $5/month