HealthChecks state

[lkurzyniec]

Idea

Currently, there is no way to retrieve the current health checks state directly.

To get the status/state, it is necessary to resolve the HealthCheckService from the DI container and call CheckHealthAsync().

If either IHealthCheckPublisher is registered, or a health check endpoint is configured (e.g., endpoints.MapHealthChecks("/healthz/ready", Predicate = healthCheck => healthCheck.Tags.Contains("ready"))) and integrated with a Kubernetes readiness probe, the current state is already available as one of the above "calculate" it by invoking HealthCheckService.CheckHealthAsync() on their own.

The proposed approach is to register as singleton a transfer object (ie HealthChecksState) and stores there a RefreshDate and the HealthReport.

That would make a way to easly get the health checks state as well as reduce number of calls to registered health check endpoints (as those are made by either IHealthCheckPublisher and/or readiness probe).

Motivation

1. Infrastructure Health Validation Before Job Processing
   A HostedService queries the database every 5 seconds to retrieve pending jobs. Before processing each batch, I would like to have an option to verify the health state of infrastructure dependencies (e.g., database, Redis) and proceed with job execution only when the health check status is Healthy.

2. Deployment Coordination with Kubernetes Readiness Probes
   The Kubernetes readiness probe is configured with a 90-second initial delay due to the service's startup time. During deployment, both the old and new pod instances run concurrently. I would like to pause the HostedService execution loop until the readiness probe indicates Healthy, ensuring the old pod has terminated and only the new pod is active.

---

I think, I can contribute on that, as this seems to be quite easy.

[MentalOfCrow]

There is currently no shared “current health state” in the built-in implementation. The endpoint and the publisher are intentionally separate executions.

The health-check middleware calls HealthCheckService.CheckHealthAsync for every request:
https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HealthChecks/src/HealthCheckMiddleware.cs#L47-L72

The publisher hosted service independently calls CheckHealthAsync on its timer and then passes that report to every registered IHealthCheckPublisher:
https://github.com/dotnet/aspnetcore/blob/main/src/HealthChecks/HealthChecks/src/HealthCheckPublisherHostedService.cs#L146-L178

The IHealthCheckPublisher documentation also explicitly says that publisher execution is not related to middleware execution:
https://github.com/dotnet/aspnetcore/blob/main/src/HealthChecks/Abstractions/src/IHealthCheckPublisher.cs#L10-L32

That separation is useful because a health report is not a single timeless application property. Different consumers may use different predicates/tags, periods and timeouts, and a cached report can become stale.

For your first scenario, your proposed state holder is still a good application-level pattern. I would implement it as the publisher itself so that no additional health-check run is needed:

public sealed class HealthState : IHealthCheckPublisher
{
    public sealed record Snapshot(
        HealthReport Report,
        DateTimeOffset RefreshedAt);

    private Snapshot? _current;

    public Snapshot? Current => Volatile.Read(ref _current);

    public Task PublishAsync(
        HealthReport report,
        CancellationToken cancellationToken)
    {
        Volatile.Write(
            ref _current,
            new Snapshot(report, DateTimeOffset.UtcNow));

        return Task.CompletedTask;
    }
}

Register the same singleton under both service types:

builder.Services.AddSingleton<HealthState>();
builder.Services.AddSingleton<IHealthCheckPublisher>(sp =>
    sp.GetRequiredService<HealthState>());

builder.Services.Configure<HealthCheckPublisherOptions>(options =>
{
    options.Predicate = registration =>
        registration.Tags.Contains("ready");
    options.Delay = TimeSpan.Zero;
    options.Period = TimeSpan.FromSeconds(10);
});

The worker should treat all three cases conservatively: no snapshot yet, an old snapshot, and a non-healthy report. For example, require Current != null, Status == Healthy, and UtcNow - RefreshedAt below a configured maximum age. Publishing one immutable snapshot atomically also prevents readers from observing a report/time pair from different refreshes.

I would not make MapHealthChecks silently return this cached report. If you need a cached diagnostic endpoint, expose a separate endpoint with an explicit name such as /healthz/last and include RefreshedAt, while keeping the Kubernetes probe semantics clear.

There is a separate issue with the deployment use case: Kubernetes readiness is a per-pod traffic-routing signal. A new pod becoming ready does not prove that the old pod has terminated, and an in-process health snapshot cannot coordinate two replicas. If exactly one replica may process a job, use queue consumer semantics, a database/distributed lease, or Kubernetes leader election. Health checks can prevent a worker from starting work when its own dependencies are unhealthy, but they should not be the exclusivity mechanism.

So I would support a reusable publisher-backed state holder as an application pattern, but not a universal framework cache: its predicate, freshness policy and failure behavior must be explicit for each consumer.

If this addresses both scenarios, you can mark it as the accepted answer so future readers can find the distinction between health state and coordination.

[lkurzyniec]

@MentalOfCrow thanks for your reply!
I understand separaion - middleware vs publisher is all about on-demand vs timer/periodic. That's clear and reasonable.
I like your approach - with minimal code I can achieve what I need.
Still, it will not reduce number of calls registered health check endpoints, it would rather increase that, but I can live with that.