Table of Contents

Class QuartzHealthCheckOptions

Namespace
Quartz
Assembly
Quartz.dll
public sealed class QuartzHealthCheckOptions
Inheritance
QuartzHealthCheckOptions
Inherited Members

Properties

ClusterCheckinTolerance

How many of its own check-in intervals a clustered node may go without checking in before the check reports Degraded. 3 by default; null or 0 turns the reading off.

public double? ClusterCheckinTolerance { get; set; }

Property Value

double?

Remarks

The rest of this check asserts that the scheduler can fire and that its store answers. Neither says anything about the cluster manager, which runs on its own timer: a node whose check-in loop has wedged still answers a store query, still reports Running, and is meanwhile being recovered by its peers — they take its triggers because it looks dead to them, while its own probe says it is fine.

So a clustered scheduler is also asked when it last checked in, through SchedulerQueryExtensions' cluster listing, and a last check-in older than this many of the node's own configured intervals is reported as degraded rather than healthy. Three because that is the same order of magnitude cluster recovery uses to decide a node is gone — one interval is an ordinary scheduling delay, and a node that has missed three is not merely late.

The reading happens only when the store says it is clustered, so a scheduler on an in-memory or unclustered store makes no extra query. Set this to null or 0 to make no query at all.

FailureStatus

The HealthStatus reported when the check fails. When null the default (Unhealthy) is used.

public HealthStatus? FailureStatus { get; set; }

Property Value

HealthStatus?

Name

The name used to register the health check.

public string? Name { get; set; }

Property Value

string

Remarks

Left unset, the check is called quartz-scheduler, or quartz-scheduler-<scheduler name> for a named scheduler — which is why it is nullable rather than carrying one of those as its value: the name depends on which scheduler the check is for, and that is not known to an options object.

StandbyStatus

The HealthStatus reported while the scheduler is in Standby. When null the default (Degraded) is used.

public HealthStatus? StandbyStatus { get; set; }

Property Value

HealthStatus?

Remarks

Degraded is the right default and the wrong answer for some deployments. Standby is deliberate and reversible, so calling it healthy would hide an application that never started its scheduler and calling it unhealthy would take a node out of rotation for doing what it was told. But a report is only read by whoever it reaches: an ASP.NET Core application can remap degraded on the endpoint with MapHealthChecks(…, new HealthCheckOptions { ResultStatusCodes = … }), while a worker has no endpoint at all — its only reader is the probe that asks the HealthCheckService directly, and a standby node it must not route to has to say Unhealthy here.

This is the standby verdict alone. A scheduler still in Created because AutoStart is false also reports degraded, and keeps doing so: that is a window between the host starting and the application pressing start, not a state a node sits in.

Tags

Tags associated with the health check, allowing it to be filtered (for example into separate liveness and readiness probes).

public List<string> Tags { get; }

Property Value

List<string>

Remarks

Get-only with an in-place initializer, like every other collection on a Quartz options type: a configuration binder binds into a non-null collection without needing a setter, and one configure callback cannot discard the tags another added. Add to it — options.Tags.Add("ready") — rather than assigning a new collection.