Class QuartzHealthCheckOptions
- Namespace
- Quartz
- Assembly
- Quartz.dll
Options for the Quartz scheduler health check registered by AddQuartz(IHealthChecksBuilder, Action<QuartzHealthCheckOptions>?) and by AddQuartzHealthChecks(IQuartzBuilder, Action<QuartzHealthCheckOptions>?).
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
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
Name
The name used to register the health check.
public string? Name { get; set; }
Property Value
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
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
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.