Introduction
A process can be running while the application is unable to serve requests. It may have lost its database connection, failed to initialize an essential component, or become stuck during startup.
Health checks give deployment platforms and monitoring systems a way to evaluate application state. The important part is defining what each health signal actually means.
1. Separate liveness from readiness
These checks answer different questions:
- Liveness: Is the process alive and functioning well enough that restarting it might help?
- Readiness: Is the application ready to receive traffic?
- Dependency health: Are important downstream services available?
A temporary database outage does not always mean the process should be restarted. Restarting every replica during a database incident can make recovery harder.
2. Register basic health checks
ASP.NET Core supports health checks through its health-check services:
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddHealthChecks();
var app = builder.Build();
app.MapHealthChecks("/health");
app.Run();This exposes a basic health endpoint. It does not automatically prove that the database, queue, or other dependencies are healthy.
Use separate endpoints or carefully configured health-check policies when the deployment platform needs different signals for liveness and readiness.
3. Check dependencies selectively
For critical dependencies, register appropriate health checks—for example, a database connectivity check. Avoid calling every downstream service on every health probe if doing so creates unnecessary load.
Think carefully about failure behavior. If an optional recommendation service becomes unavailable, the application may still be able to serve its core functionality.
Readiness should reflect whether the instance can safely handle the traffic it is about to receive.
4. Keep responses safe
Health endpoints can reveal infrastructure details if they return raw exception messages or connection information.
Expose only the information needed by the platform or authorized operators. Detailed diagnostics should remain in protected logs and monitoring systems.
If endpoints are externally reachable, consider network restrictions and the application’s threat model.
5. Configure probes with sensible thresholds
Deployment platforms commonly support probe intervals, timeouts, and failure thresholds. Configure them to tolerate brief delays without masking prolonged failures.
Test startup delays, dependency outages, recovery, and shutdown behavior. Verify that the orchestrator removes unready instances from traffic without repeatedly restarting healthy processes.
Conclusion
Useful health checks distinguish process liveness from the ability to serve requests. Define the purpose of each endpoint, test failure and recovery behavior, and avoid turning temporary dependency problems into unnecessary restarts.
