All 15 Health Checks questions
More in Health Checks
How do you implement a custom health check by implementing IHealthCheck, such as checking database connectivity? How do you customize the JSON response format of the health check endpoint, since the default output is just plain text status? How do you add pre-built health checks for common external dependencies like SQL Server, Redis, or a URL endpoint, using the community AspNetCore.Diagnostics.HealthChecks packages? How do health checks interact with dependency injection scoping, particularly for checks that need a scoped service like a DbContext? How would you write an integration test verifying that your health check endpoint correctly reports Unhealthy when a dependency is down? How would you exclude health check endpoints from other cross-cutting middleware like authentication, logging, or rate limiting that shouldn't apply to frequent automated health polling? How do you differentiate liveness and readiness health checks using tags, and why does Kubernetes treat these two probe types differently? How would you implement a health check that reports Degraded (rather than a binary Healthy/Unhealthy) based on a performance threshold, like elevated database query latency? How would you integrate health check results with the AspNetCore.HealthChecks.UI package to get a persistent, historical dashboard view of health status over time? How would you set a per-check timeout to prevent one slow or hanging dependency check from blocking the entire /health endpoint response indefinitely?
Advertisement
ASP.NET Core › Health Checks

Why should the detailed /health endpoint (with full dependency status breakdown) generally not be exposed publicly on the internet, and how do you restrict access to it?

Intermediate

Answer

A detailed health check response can leak sensitive infrastructure information (which database provider is used, internal service names, version numbers, error messages potentially revealing internal architecture) to anyone who can reach the endpoint -- best practice restricts detailed health endpoints to internal networks only (via network-level restrictions, a reverse proxy rule, or [Authorize] combined with a policy requiring an internal-only claim), while optionally exposing a minimal, information-free public endpoint (just 200 OK / 503) for basic external uptime monitoring.
// Program.cs -- separate detailed (internal) and minimal (public) health endpoints
app.MapHealthChecks("/health/detailed", new HealthCheckOptions {
    ResponseWriter = WriteDetailedJson
}).RequireAuthorization("InternalOnly");

app.MapHealthChecks("/health", new HealthCheckOptions {
    ResponseWriter = (context, report) => context.Response.WriteAsync(report.Status.ToString())
});  // minimal, publicly safe
Real-world example A security review flags that an API's detailed /health endpoint was publicly exposing its exact SQL Server version, Redis hostname, and internal service names, leading the team to restrict the detailed endpoint to internal network access only while keeping a minimal public endpoint for basic uptime monitoring.

Common follow-ups: What network-level (versus application-level) approaches exist for restricting access to the detailed endpoint?;What specific pieces of information are most risky to leak via a health check response?

Security Headers Antiforgery & CSRF Protection;Authorization
All 15 Health Checks questions