Health Checks in ASP.NET Core

Introduction

Kubernetes and Azure load balancers need /health endpoints — ShopNest microservices report SQL, Redis, and downstream API status via ASP.NET Core health checks.

After this article you will

• Add health checks for SQL Server and Redis
• Expose /health/live and /health/ready
• Write custom health checks
• Use Health Checks UI dashboard
• Integrate with container orchestration

Prerequisites

• Article 48 — Caching in ASP.NET Core
• ShopNest API, EF Core, and DI from prior modules

Concept deep-dive

builder.Services.AddHealthChecks()
    .AddSqlServer(connectionString, name: "sql")
    .AddRedis(redisConnection, name: "redis")
    .AddCheck<PaymentGatewayHealthCheck>("payment-api");

app.MapHealthChecks("/health/ready", new HealthCheckOptions
{
    Predicate = check => check.Tags.Contains("ready"),
    ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse
});
app.MapHealthChecks("/health/live", new HealthCheckOptions
{
    Predicate = _ => false // process up only
});

Liveness: app process running. Readiness: can accept traffic (DB up). K8s uses both probes differently.

Hands-on — ShopNest Production Microservices Monitoring

1. Register SQL + Redis checks on ShopNest.Api.
2. Custom check calls payment gateway ping URL.
3. Health Checks UI in Development at /health-ui.
4. Docker Compose healthcheck directive pointing to /health/ready.

Common errors & best practices

• Readiness includes optional dependency — pod never ready.
• Health endpoint requires auth — load balancer gets 401.

Interview questions

Q: Liveness vs readiness?
A: Live = restart if dead; Ready = remove from load balancer if dependencies fail.

Q: Why health checks?
A: Orchestrators route traffic only to healthy instances.

Summary

• Health checks expose dependency status
• Separate live vs ready for Kubernetes
• Custom checks for external APIs
• Health UI aids local and staging diagnostics

Previous: Caching in ASP.NET Core
Next: AutoMapper

FAQ