Health Checks

Endatix exposes health check endpoints so you can monitor the application and its dependencies. With default configuration you get a self-check and database checks (when persistence is configured), plus a simple HTML UI and a detailed JSON report.

This page focuses on API usage (endpoints, JSON shape, customizing checks and middleware). For configuration options (path via options, filtering by tags, custom IHealthCheck implementation), see Health Checks Configuration.

Endpoints

When health checks middleware is enabled (default with app.UseEndatix()), the following are available:

Path	Description
{Path}	Overall status across every registered check: Healthy, Degraded, or Unhealthy. Default path is /health.
{Path}/detail	JSON report with status, per-check results, and total duration.
{Path}/ui	HTML page listing each check with status and duration.
{LivenessPath}	Liveness. Only checks tagged self or live — never the database. Default /alive.
{ReadinessPath}	Readiness. Only checks tagged ready — the database checks. Default /ready.

Example with default paths:

• /health — Overall status, all checks (humans and dashboards)
• /health/detail — Full JSON (for CI/monitoring)
• /health/ui — Human-readable UI
• /alive — Liveness probe
• /ready — Readiness probe

:::warning Point your orchestrator at /alive and /ready, not /health

/health includes the database. A livenessProbe pointed at it restarts every pod when the database blips — removing capacity exactly when the system is already degraded, and restarting a process cannot fix a database that is down. Liveness answers "is this process running?" and belongs on /alive; readiness answers "can this pod serve traffic?" and belongs on /ready.

/ready is also narrower than /health on purpose: it runs only ready-tagged checks, so a custom check you add does not silently start evicting pods from the Service endpoints.

The bundled Helm chart is already configured this way — see probes in its values.yaml. :::

Paths are configurable via Endatix:Hosting:HealthCheckPath, Endatix:Hosting:LivenessPath and Endatix:Hosting:ReadinessPath.

Default checks

With builder.Host.ConfigureEndatix() and app.UseEndatix():

• endatix-self — Process-alive check, tagged self. Registered unconditionally; the name is Endatix-owned so it cannot collide with Aspire ServiceDefaults' own self check.
• database — EF Core health check for the main AppDbContext when persistence is configured.
• identity-database — EF Core health check for AppIdentityDbContext when identity persistence is configured.

Database checks use tags db and ready; the self check is tagged self. Those tags are what /ready and /alive filter on, so a custom check joins a probe only if you tag it accordingly.

JSON detail shape

Use it to properly configure your health monitoring tool. When you request the health detail endpoint e.g. GET /health/detail, you will get JSON response with the following structure:

{
  "status": "Healthy",
  "checks": [
    {
      "name": "endatix-self",
      "status": "Healthy",
      "description": null,
      "data": {}
    },
    {
      "name": "database",
      "status": "Healthy",
      "description": null,
      "data": {}
    }
  ],
  "totalDuration": "00:00:00.0423456"
}

Customizing checks (host)

Use the health checks builder when configuring the host:

builder.Host.ConfigureEndatix(endatix => endatix
    .HealthChecks.UseDefaults()
    .AddCheck("custom", () => HealthCheckResult.Healthy("OK")));

Or add checks after defaults:

builder.Host.ConfigureEndatixWithDefaults(endatix => endatix
    .HealthChecks.AddCheck("my-service", () => HealthCheckResult.Healthy()));

Customizing middleware (path and writers)

Customize the health check path or response writer when configuring the pipeline:

app.UseEndatix(middleware => middleware
    .UseHealthChecks("/healthz"));

With a custom response writer:

app.UseEndatix(middleware => middleware
    .UseHealthChecks("/health", opts => opts.WithResponseWriter(MyCustomWriter)));

Best practices

• Use tags (e.g. db, ready) to group checks and, if needed, add a separate readiness route that only runs a subset.
• Rely on /health/detail in CI or monitoring for a stable JSON shape.
• Add custom checks for critical dependencies via AddCheck or Builder.Add... on the health checks builder.
• When you adopt Aspire, the existing DB and custom checks compose with Aspire's defaults. Endatix's own process check is named endatix-self so it sits alongside Aspire's self check rather than colliding with it.