Comparison

Five .NET libraries schedule background work. Every cell below was read from the named project's own documentation or source at a pinned version, and every cell that is not Quartz's links its source. Rows where Quartz.NET is the more expensive answer say so; Where Quartz.NET costs more than it is worth collects them.

Read as of 29 September 2026. If a cell no longer matches its link, the link is right — please open an issue.

• "None": the project's documentation has no such concept, and its source at the pinned version has none. You can usually still write the code yourself.
• "—": the row does not apply to that library.

What each one is

• Quartz.NET is a scheduler. A trigger is a stored object with a schedule, time zone, misfire instruction, calendar and priority, and the scheduler fires it once, on time, on one node of however many are running.
• Hangfire is a background job processor first: a queue with a durable state machine (enqueued, processing, succeeded, failed) and a dashboard built around it. A recurring job is a cron string that enqueues into it.
• TickerQ is a source-generated dispatcher: an attribute on a method, a Roslyn generator for the registration, no reflection on the dispatch path. It has a one-shot ticker and a cron ticker.
• Wolverine is a message bus with cron since 6.34. opts.Schedules.ScheduleRecurring publishes a message on a schedule, using the bus's delivery, durability and replay. It is not a scheduler; Quartz.NET with Wolverine covers which of the two should own a schedule.
• Coravel is an in-process convenience layer for ASP.NET Core: a scheduler, a queue, a cache and an event dispatcher, all in memory, in one small package.

Declaring a job

Before 4.2 Quartz parsed cron only at run time, and TickerQ's generator won this row. Now an analyzer inside Quartz.nupkg parses a cron literal or const with the run-time parser and fails the build on an error (Compile-Time Checks), and [QuartzJob] and [CronTrigger] declare a job and its schedule on the class for a source generator to register. An expression built at run time is still checked at run time, with CronExpressionBuilder and the "when does this fire" helper.

Coravel has a method per cadence: EveryTenMinutes(), DailyAt(3, 0), Weekday(). Quartz has one member per idea, and writes the schedule inline: t.WithCronSchedule(cron => cron.Every(TimeSpan.FromMinutes(10))), cron.AtTime(new TimeOnly(3, 0)), cron.OnWeekdays(). See Building CronTriggers.

Trigger kinds and cron grammar

A firing the process was down for

Calendars and time zones

Elsewhere, "not on public holidays" is a check in the job body.

Running once when several nodes are up

Quartz fires each trigger once, because acquisition claims the trigger's row before the job runs. A firing is at most once unless recovery is requested, which makes it at least once. No library here promises exactly once; Hangfire's best practices ask for re-entrant methods because it retries, and its throttling page says a mutex does not prevent simultaneous execution of one job. Write jobs so a second run is harmless — Best Practices.

Concurrency control

Only Quartz counts a limit across nodes for free: "this tenant gets eight threads, however many nodes are up" is counted by the store, not per process.

Retries and failure

Hangfire retries by default; Quartz retries when the trigger, its job type or the scheduler names a policy, and jitters only when the policy says so. Quartz holds the wait in the store, so a node that dies during a backoff does not lose the retry.

Continuations and chaining

Before 4.2 Quartz had only JobChainingJobListener: links were not persisted, the follow-up ran on the parent's node, and it ran even when the parent threw. Now the link is in the store, so a crash between the parent finishing and the release cannot lose it, and a continuation whose condition was not met is discarded. See Job Continuations.

Persistence

The dashboard, and what it allows before you configure anything

Hangfire's per-state lists are better for browsing failures by kind, and it requeues any failed job. Quartz's History page has a Failed after retries filter and a Run again button on each occurrence that gave up (When the policy gives up). Run again needs the job still stored: a non-durable job is deleted with its last trigger. The page also filters by result (Succeeded, Skipped, Failed, Cancelled) and by one job or trigger, and charts runs over time. The Jobs page shows each job's last run, last success and a failing ×N count from its run status.

One dashboard fronts a fleet. Workers that all run QuartzScheduler list apart when each AddQuartzHttpClient registration sets HttpClientOptions.Target: w1/QuartzScheduler, w2/QuartzScheduler. A worker the dashboard cannot dial calls UseDashboardAgent instead, and the dashboard accepts it with AcceptAgents.

Observability

Trimming and native AOT

Target frameworks

Licence and price

Where Quartz.NET costs more than it is worth

• The first five minutes are longer. TickerQ is two registration lines and an attribute; Coravel is two lines and a fluent chain. Quartz's shortest form is comparable, and a delegate job is one call with the job as a lambda. A recurring schedule on a database still adds a builder chain, a connection string, a driver package and a schema.
• A schedule costs a row. With a persistent store, adding a schedule is an INSERT and a round trip, and each firing costs a few more. TickerQ's in-memory default and Coravel are a dictionary insert. For thousands of short-lived one-off firings, use one durable job per job type with a trigger per firing.
• Retry and jitter are opt-in. Hangfire retries every job by default and spreads the attempts. Quartz retries nothing until a trigger, a job type ([RetryPolicy]) or the scheduler (UseDefaultRetryPolicy) names a policy, and waits exactly the policy's waits unless it names a jitter. One line opts a whole scheduler in.
• Routing is by execution group, not by queue. Hangfire's [Queue], with servers subscribing to different sets, routes work. A node serves or refuses execution groups, which is the same shape; a limit on the group bounds how much of it runs at once. What stays different: there is no per-queue ordering, and the group is on the trigger, not an attribute on the job type.
• A message may belong to a bus. An application already running Wolverine with an outbox, wanting "publish X every weekday at 03:00", should use Wolverine's schedule rather than a second runtime and set of tables — Quartz.NET with Wolverine covers both directions.
• .NET Framework is 3.x territory. Quartz 4.x is net10.0 only; Hangfire still ships net451, and is the only one of the five whose current line a .NET Framework application can take.

Choose:

• Quartz.NET for stored schedules with calendars, time zones, misfire policies and priorities; a cluster that fires each trigger on one node; limits counted across nodes; retries held in the store.
• Hangfire for a queue with a state-machine dashboard, retry on by default, or .NET Framework on a current line.
• TickerQ or Coravel for the shortest setup, or many short-lived in-memory firings.
• Wolverine's own schedule when the occurrence is a message in an application already on Wolverine.

Coming from one of these

• Coming from Hangfire — the API mapping, and the semantics that differ
• Coming from TickerQ — the same, shorter
• Quartz.NET with Wolverine — running both in one host, and deciding which owns a schedule