Fast jede .NET-Anwendung braucht irgendwann Arbeit ausserhalb einer Web-Anfrage: E-Mails versenden, Dateien importieren, Berichte erzeugen, mit anderen Systemen synchronisieren. Dafür gibt es vier gängige Wege — Hangfire, Quartz.NET, das jüngere TickerQ und den eingebauten BackgroundService. Sie lösen überlappende, aber unterschiedliche Probleme. Dieser Vergleich hilft bei der Wahl für Ihr Projekt.
Stand September 2026, auf Basis der Dokumentation der jeweiligen Projekte. Details ändern sich zwischen Releases — prüfen Sie die aktuelle Dokumentation für alles, was Ihre Entscheidung trägt.
| Hangfire | Quartz.NET | TickerQ | BackgroundService | |
|---|---|---|---|---|
| Grundmodell | Job-Queue + Scheduler | Scheduler (Jobs + Trigger) | Scheduler („Ticker") | Langlaufende Schleife im eigenen Prozess |
| Persistenz | Ja — SQL Server eingebaut; PostgreSQL, Redis u. a. über offizielle Pro- oder Community-Pakete | Optional — standardmässig im Speicher, ADO.NET-Job-Store für SQL Server, PostgreSQL, MySQL, SQLite u. a. | Ja — über Entity Framework Core; auch im Speicher möglich | Nein |
| Fire-and-forget / eingereihte Jobs | Ja | Über einmalige Trigger möglich, nicht der Schwerpunkt | Ja (einmalige „Time Ticker") | Selbst bauen (z. B. mit Channels) |
| Wiederkehrende (Cron-)Jobs | Ja | Ja, dazu einfache und kalenderbasierte Trigger | Ja | Selbst bauen (PeriodicTimer) |
| Automatische Wiederholungen | Ja, standardmässig 10 Versuche mit Back-off | Keine eingebaute Retry-Policy; ein Job kann ein erneutes Auslösen anfordern | Ja, konfigurierbar | Nein |
| Eingebautes Dashboard | Ja | Nein (Community-Projekte existieren) | Ja | Nein |
| Übersteht einen Neustart | Ja | Nur mit persistentem Job-Store | Mit aktivierter Persistenz | Nein — laufende Arbeit geht verloren |
| Lizenz | LGPL 3.0 (Kern), kommerzielle Pro-Erweiterungen | Apache 2.0 | Open Source | Teil von .NET |
| Reife | Seit 2014, sehr grosse Verbreitung | Einer der ältesten .NET-Scheduler | Junges Projekt, wächst schnell | — |
Die Grundidee von Hangfire: Ein Aufruf von BackgroundJob.Enqueue(() => ...) soll so einfach sein wie der direkte Methodenaufruf — nur dass der Aufruf in einen persistenten Speicher serialisiert und von einem Worker ausgeführt wird, eventuell auf einem anderen Server, mit automatischen Wiederholungen bei Fehlern. Verzögerte Jobs, wiederkehrende Jobs per Cron-Ausdruck und Continuations bauen auf derselben Grundlage auf.
Stärken: sehr wenig Code für den Einstieg, Arbeit übersteht Neustarts, fehlgeschlagene Jobs werden automatisch wiederholt, und das eingebaute Dashboard zeigt Queues und jüngste Jobs. Es ist mit Abstand die verbreitetste Option — fast jedes Problem, auf das Sie stossen, hatte schon jemand und hat es beantwortet.
Achtung: Das Dashboard läuft in Ihrer Anwendung und zeigt nur, was der Speicher noch enthält — erfolgreiche Jobs verfallen standardmässig nach etwa einem Tag (warum, und was hilft). Wer die Signatur einer Job-Methode ändert, während noch alte Jobs eingereiht sind, macht diese kaputt. Redis-Speicher und Batches gehören zu den kommerziellen Pro-Paketen.
Quartz.NET ist eine Portierung des Java-Schedulers Quartz und trennt Jobs (was zu tun ist) von Triggern (wann es zu tun ist). Ein Job kann mehrere Trigger haben; Trigger können cron-basiert oder einfache Intervalle sein oder mit Kalendern kombiniert werden, die etwa Feiertage ausschliessen. Misfire-Anweisungen legen genau fest, was passiert, wenn ein Lauf verpasst wurde, weil der Scheduler nicht lief.
Stärken: das ausdrucksstärkste Planungsmodell der vier, Clustering mit gemeinsamem Datenbank-Job-Store, freizügige Apache-2.0-Lizenz und viele Jahre Produktionseinsatz.
Achtung: Es ist keine Arbeits-Queue — Tausende Ad-hoc-Jobs aus dem Code einzureihen ist nicht der vorgesehene Einsatz. Es gibt keine eingebaute Retry-Policy (ein fehlschlagender Job kann ein erneutes Auslösen anfordern, Back-off und Versuchsgrenzen sind aber Ihre Sache) und kein offizielles Dashboard. Der standardmässige Job-Store im Speicher verliert bei einem Neustart alles.
TickerQ geht technisch einen anderen Weg: Jobs werden per Source Generator statt Reflection gefunden, die Persistenz läuft über Entity Framework Core, und ein Dashboard gibt es als Paket. Es unterscheidet Cron Ticker (wiederkehrend) von Time Tickern (einmalig zu einem Zeitpunkt).
Stärken: eine saubere, moderne API, passt gut zu Anwendungen, die ohnehin EF Core nutzen, keine Reflection zur Laufzeit.
Achtung: Es ist ein junges Projekt. Weniger Leute haben es über Jahre durch Grenzfälle im Betrieb getragen, und es gibt weniger beantwortete Fragen, wenn etwas schiefgeht. Das ist kein Grund, es zu meiden — aber ein Grund, die Fehlerfälle, die Ihnen wichtig sind (Neustarts, Deploys, parallele Server), vorher zu testen.
Der BackgroundService von ASP.NET Core (ein IHostedService) führt eine langlebige Schleife in Ihrem Prozess aus. Zusammen mit PeriodicTimer oder System.Threading.Channels deckt er einfache Anforderungen ohne jede Abhängigkeit ab.
Stärken: keine Abhängigkeiten, volle Kontrolle, nichts zu konfigurieren.
Achtung: Es gibt keine Persistenz, keine Wiederholung, keine Historie und keine Sichtbarkeit. Was beim Beenden des Prozesses gerade läuft, ist weg. Mit mehreren Replicas führt jede Replica die Schleife aus — Sie brauchen also eigene Sperren, damit Arbeit nicht doppelt passiert. Wer sich dabei ertappt, Wiederholungen und eine Statustabelle zu bauen, sollte ein Framework nehmen.
BackgroundService und Quartz.NET mit Speicher-Job-Store weg.Eingebaute Dashboards zeigen den aktuellen Zustand innerhalb der laufenden Anwendung; sie senden keine Alerts und verschwinden mit dem Prozess, in dem sie leben. QueueHawk schliesst diese Lücke für Hangfire: Ein Agent streamt jeden Zustandswechsel aus Ihrer Anwendung, hält eine durchsuchbare Historie über Deploys hinweg und alarmiert per Slack, Teams, E-Mail oder Webhook bei Fehlerraten und ausbleibenden Heartbeats. Quartz.NET, TickerQ und Hosted Services unterstützt es derzeit nicht. Wer in einem davon mit Cron-Ausdrücken plant, sieht im Cron-Ausdruck-Explainer, wann ein Job genau läuft.
Keines ist grundsätzlich besser. Hangfire ist die stärkere Wahl, wenn Sie vor allem Arbeit aus Ihrer Anwendung einreihen und Wiederholungen, Persistenz und ein Dashboard ohne Eigenbau wollen. Quartz.NET ist stärker, wenn die Planung selbst das Schwierige ist: komplexe Trigger, Kalender mit ausgeschlossenen Feiertagen und präzise Behandlung verpasster Läufe.
TickerQ wird von einer wachsenden Zahl von Teams produktiv eingesetzt, ist aber deutlich jünger als Hangfire und Quartz.NET — das Ökosystem an Speicheroptionen, Integrationen und beantworteten Fragen ist kleiner. Prüfen Sie es gegen Ihre eigenen Anforderungen und sehen Sie sich Release-Historie und Issue-Tracker an, bevor Sie sich festlegen.
Wenn die Arbeit billig zu verlieren und leicht zu wiederholen ist: das Abfragen einer Queue, die selbst dauerhaft ist, das Auffrischen eines Caches oder eine periodische Bereinigung, bei der ein verpasster Lauf egal ist. Sobald Arbeit einen Neustart überstehen muss, Wiederholungen oder eine Historie braucht, ist ein Job-Framework die bessere Wahl.
Derzeit nicht. Der QueueHawk-Agent klinkt sich in Hangfires eigene Zustandswechsel-Pipeline ein und unterstützt deshalb aktuell nur Hangfire. Unterstützung für weitere Scheduler hängt von der Nachfrage ab — schreiben Sie uns an team@queuehawk.com, wenn Sie sie brauchen.
Historie, die Deploys übersteht, Fehlerraten- und Heartbeat-Alerts. Kostenlos für eine Application.