patterncsharpdotnetModerate
Health checks: registering and exposing liveness vs readiness probes
Viewed 0 times
health checks aspnetliveness readiness probeMapHealthChecks tagsKubernetes health endpointsAddHealthChecks
kubernetes
Problem
Kubernetes and load balancers need separate liveness (is the process alive?) and readiness (can it serve traffic?) endpoints. A single /health endpoint that mixes both causes cascading restarts — a temporarily unready pod gets killed.
Solution
Register tagged health checks and map separate endpoints:
Use AspNetCore.HealthChecks.UI for a dashboard or serialize results as JSON:
builder.Services.AddHealthChecks()
.AddDbContextCheck<AppDbContext>(tags: new[] { "ready" })
.AddUrlGroup(new Uri("https://dep.external/health"),
tags: new[] { "ready" })
.AddCheck("self", () => HealthCheckResult.Healthy(), tags: new[] { "live" });
// Map endpoints filtered by tag
app.MapHealthChecks("/health/live", new HealthCheckOptions
{
Predicate = check => check.Tags.Contains("live")
});
app.MapHealthChecks("/health/ready", new HealthCheckOptions
{
Predicate = check => check.Tags.Contains("ready")
});Use AspNetCore.HealthChecks.UI for a dashboard or serialize results as JSON:
app.MapHealthChecks("/health/detail", new HealthCheckOptions
{
ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse
});Why
Liveness failing should restart the pod. Readiness failing should remove it from the load balancer. If both are mixed, a database blip causes pod restarts instead of just traffic re-routing.
Gotchas
- AddDbContextCheck requires Microsoft.Extensions.Diagnostics.HealthChecks.EntityFrameworkCore package
- Health check endpoints should be accessible without authentication — exclude them from auth middleware
- Slow health checks (>1s) can queue up on Kubernetes and cause false readiness failures under load
Revisions (0)
No revisions yet.