Quartz.AspNetCore

Quartz.AspNetCore adds what a Quartz.NET scheduler wants from an ASP.NET Core application: an HTTP API that exposes scheduler management endpoints.

Hosting and the scheduler's health check are both in the core Quartz package — AddQuartz, AddQuartzHostedService and the health check need no extra reference. This package brings ASP.NET Core along with it, so take it for the HTTP API rather than for the check. Quartz 3's AddQuartzServer, which registered the hosted service and a health check together, is gone.

Installation

dotnet add package Quartz.AspNetCore

Usage

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);

builder.AddQuartz();
builder.Services.AddQuartzHttpApi();
builder.AddQuartzHostedService(options => options.WaitForJobsToComplete = true);
builder.Services.AddHealthChecks().AddQuartz();

WebApplication app = builder.Build();

app.MapQuartzHttpApi().RequireAuthorization();
app.MapHealthChecks("/healthz");

The API manages jobs and triggers, so authorize it: MapQuartzHttpApi returns the endpoint convention builder to say so on, and a mapping that says nothing refuses to start. It adds no authentication of its own, every route mutates, and a job scheduled through it names its type as a string the request supplies — which, with Quartz.Jobs on the host's probing path, reaches NativeJob and its process. Say AllowAnonymous() where you mean it, or AddQuartzHttpApi(options => options.ReadOnly = true) where nothing should write through the API at all. AddQuartz and the health check beside it come from the core package; serving the health report at /healthz is what needs ASP.NET Core.

Mapping the API also records what its schedulers run and miss, and serves it under …/schedulers/{name}/history — which is what lets a dashboard in another process show a History page. It is kept in memory and bounded; AddQuartzExecutionHistory(options => options.MaxEntriesPerScheduler = 0) opts out.

Documentation

• ASP.NET Core integration
• HTTP API
• Quartz.NET documentation