Blog

Getting Slack, Teams, or email alerts when a Hangfire job fails or goes silent

The stock Hangfire dashboard is entirely passive. It will happily show you a wall of failed jobs — the moment you think to open it. It never pushes anything to you, which means the usual way teams find out something's wrong is a client calling to ask why their nightly report never arrived.

Two different ways a job pipeline actually breaks

In practice, "something's wrong with my background jobs" almost always means one of two distinct failure modes, and they need different detection:

Jobs are running and failing

The obvious case: a job type starts throwing exceptions — a downstream API changed its contract, a database constraint started rejecting rows, whatever it is. An error-rate alert rule watches for this directly: if failures for a job type cross a threshold within a time window, it fires. A cooldown period keeps it from re-firing on every single failure once you're already aware, and it resolves itself automatically once the rate drops back down — no manual "close this alert" step.

Nothing is running at all — and nothing looks wrong

The sneakier case: the Hangfire server process is technically alive, but has stopped picking up jobs entirely — no exceptions, no failed-job list, because nothing is being attempted at all. A pure job-event stream can't detect this, because there are no events to look at. That's what a heartbeat-timeout alert rule is for: each Hangfire server reports in periodically, and if a server hasn't reported in past its timeout, that's the alert, independent of whatever the job-event history shows.

Where the alert actually goes

Both rule types route through the same notification channels: Slack (incoming webhook), Microsoft Teams (incoming webhook), or email. You wire up a channel once per team/destination, then attach it to whichever alert rules should notify it — a given rule can notify more than one channel at once (e.g. both Slack and email for something urgent).

Setup is self-service

Both alert rule types come with sensible presets (e.g. a 90-second heartbeat timeout, common error-rate windows) so you're not filling in raw numbers by default, but every threshold — cooldown, error count, time window, heartbeat timeout, which job type it applies to — is editable per application from the dashboard. Creating a notification channel and testing it end-to-end (a real test message, not a simulated one) takes under a minute.

Need to create the webhook itself first? See setting up a Slack incoming webhook or setting up a Microsoft Teams webhook.

See also: why job history disappears in the first place, and how this scales once you're watching more than one application.

← All articles Try QueueHawk free →

Find out before your client does

Free for one application, no card required.

Start free