Hangfire vs. Quartz.NET vs. TickerQ vs. Coravel: .NET-Job-Scheduler 2026

Jedes .NET-Team, das Hintergrundarbeit plant, vergleicht am Ende dieselben Bibliotheken. Hier ist die ehrliche Version dieses Vergleichs — inklusive der Option, die in den Bibliotheks-Docs nicht steht.

Die Antwort in 30 Sekunden

• Quartz.NET — der reifste und als Scheduler fähigste: reiche Cron-Trigger, Kalender, Misfire-Strategien, DB-gestütztes Clustering. Kein Dashboard, mehr Zeremonie.
• Hangfire — der populärste für Hintergrundjobs allgemein: Fire-and-Forget, verzögerte und wiederkehrende Jobs mit einem starken Dashboard. Recurring-Cron ist ein Feature, nicht der Kern.
• TickerQ — der Neuling: Source-Generator-basiert (keine Reflection), EF-Core-Persistenz, Live-Dashboard, kein Polling. Modern, aber jung — Reife gegen Ihre Risikotoleranz abwägen.
• Coravel — der einfachste: fluente In-Process-Planung ohne Infrastruktur. Keine Persistenz — ein Neustart verliert den Zustand, eine einzelne Instanz wird vorausgesetzt.
• FluentScheduler — historisch beliebt, faktisch im Wartungsmodus; in alten Codebasen okay, für neue schwer zu empfehlen.

Feature-Vergleich

	Quartz.NET	Hangfire	TickerQ	Coravel
Cron-Zeitpläne	Ja (6 Felder, reich)	Ja (Recurring Jobs)	Ja	Fluent-API (Daily(), Cron())
Persistenz	ADO.NET-Stores	SQL/Redis	EF Core	Keine (In-Memory)
Übersteht Neustarts	Ja (mit Store)	Ja	Ja	Nein
Multi-Node-Clustering	Ja (DB-Locks)	Ja (storagebasiert)	Ja	Nein
Dashboard	Nein (Drittanbieter)	Ja	Ja	Nein
Retries	Über Listener/Policies	Automatisch, konfigurierbar	Konfigurierbar	Manuell
Ausführungsmodell	Polling + In-Memory	Storage-Polling	In-Memory, ohne Polling	In-Memory-Timer
Gewicht	Schwer	Mittel	Leicht-mittel	Sehr leicht

Vertiefung zu den beiden Platzhirschen: Quartz.NET vs. Hangfire.

Was alle vier teilen — und nicht beheben können

Alle laufen im Prozess Ihrer Anwendung. Das hat reale Konsequenzen:

1. Ihre App muss laufen. Ein Scheduler in einer App, die abgestürzt ist, gerade deployt oder auf null skaliert wurde, plant nichts. Unter IIS pausiert App-Pool-Recycling still alles bis zum nächsten Request.
2. Der Zustand liegt in Ihrer Datenbank (oder nirgends, bei Coravel) — Ihre Job-Tabellen, Ihre Polling-Last, Ihre Migrationen.
3. Niemand außerhalb des Prozesses schaut zu. Stirbt der Host um 01:59 und das Backup war für 02:00 fällig, scheitert jede In-Process-Bibliothek identisch: still. Der Scheduler kann Sie nicht über seinen eigenen Tod alarmieren.

Punkte 1 und 2 sind Architektur-Trade-offs, die man bewusst eingehen kann. Punkt 3 lohnt sich unabhängig von der Bibliothekswahl zu beheben: Kombinieren Sie den Zeitplan mit einem externen Heartbeat-Monitor — der Job pingt bei Abschluss; ein ausbleibender Ping wird zum Alarm per E-Mail, Slack, Discord oder Telegram. Das .NET-SDK verpackt das in ein Attribut.

Wann Sie die Bibliothek ganz überspringen sollten

Wenn ein Job auf „rufe diesen Endpunkt nach Zeitplan auf” hinausläuft — Cleanups, Report-Generierung, Cache-Warming, Webhook-Versand — ist ein In-Process-Scheduler Infrastruktur, die Sie nicht brauchen. Exponieren Sie die Arbeit als HTTP-Endpunkt und lassen Sie einen externen Scheduler sie mit Retries, Timeouts und Ausführungsprotokoll aufrufen:

jobs:
  - id: nightly-report
    name: Nightly report
    kind: http
    method: POST
    url: https://app.example.com/internal/reports/nightly
    schedule: "0 2 * * *"
    timezone: Europe/Berlin
    retries: 3
    headers:
      Authorization: Bearer ${CRON_SECRET}

Keine Job-Tabellen, keine Polling-Last, kein selbst gehostetes Dashboard — und der Zeitplan übersteht Ihre Deploys. Der volle Trade-off speziell gegen Hangfire: Hangfire-Alternative.

Empfehlungen

• Komplexe Scheduling-Logik (Kalender, Misfire-Handling, verkettete Trigger): Quartz.NET.
• Allgemeines Background-Job-System mit Enqueue/Retry/Dashboard: Hangfire.
• Greenfield, EF-Core-Shop, Dashboard ohne Hangfire-Gewicht: TickerQ evaluieren.
• Kleine App, einzelne Instanz, Jobs dürfen mal ausfallen: Coravel.
• „Rufe diese URL nach Zeitplan auf”-Jobs oder alles, was nicht still scheitern darf: den Trigger auslagern, den Handler behalten — egal, was Sie sonst betreiben.