A health check endpoint lets an Aspire host determine whether a service is running and healthy. In the dashboard, service status appears in the Resources tab. Health checks can report Healthy, Unhealthy, or Degraded; a startup failure can prevent a service from appearing as Running. section 6.5.1
Register the API service with the host
Register the API project with `.WithHttpHealthCheck("/health")`. This tells the Aspire orchestrator which path to check; it does not, by itself, map that path inside the application. A dependent service can use `.WithReference(apiService).WaitFor(apiService)` so the host waits for the API service to become healthy before starting it. section 6.5.1 section 1.7.2
Expose the corresponding HTTP endpoints in the application:
- Call `app.MapDefaultEndpoints()` in an Aspire-hosted HTTP application. Its health-check mapping includes the basic `/health` endpoint, registered through `app.MapHealthChecks()`. section 6.5.3
- Map `/alive` separately with a `HealthCheckOptions` predicate that selects checks tagged `live`. This gives callers an aliveness endpoint distinct from the basic `/health` path. section 6.5.3
Keep health checks available in production even if a starter configuration maps them only when `app.Environment.IsDevelopment()` is true. Preserve the endpoint paths, and decide what protection public production endpoints need. Health checks report a running service’s current state; they do not replace tests before deployment. section 6.5.4
For an existing project joining Aspire orchestration, add service defaults, invoke `builder.AddServiceDefaults()` during startup, map `app.MapDefaultEndpoints()`, and configure `.WithHttpHealthCheck("/health")` in the AppHost. section 10.2
