Skip to main content
Bitwarden Server provides health check endpoints to monitor the status of your deployment and its dependencies. These endpoints are critical for production monitoring, load balancers, and orchestration platforms.

Health Check Endpoints

Basic Health Check

The basic health check endpoint provides a simple status indicator:
Response:
This endpoint is suitable for:
  • Load balancer health checks
  • Kubernetes liveness probes
  • Basic uptime monitoring

Extended Health Check

The extended health check provides detailed information about all system dependencies:
Response Format:

Configuration

Health Check Services

Health checks are configured in the API service startup. The implementation is in src/SharedWeb/Health/HealthCheckServiceExtensions.cs and src/Api/Utilities/ServiceCollectionExtensions.cs:77. Default Checks:
  1. Identity Service Check
    • Verifies the Identity service OpenID configuration endpoint
    • URL: {IdentityUri}/.well-known/openid-configuration
  2. SQL Server Check
    • Validates database connectivity
    • Uses the configured connection string from globalSettings.SqlServer.ConnectionString

Self-Hosted Deployments

Health check endpoints are disabled by default for self-hosted deployments. They are only enabled for cloud deployments.
To enable health checks in self-hosted environments, you’ll need to modify the startup configuration in src/Api/Startup.cs:196.

Rate Limiting

The /alive endpoint (if configured) has rate limiting applied:
This prevents abuse while allowing regular monitoring checks.

Monitoring Integration

Kubernetes

Configure liveness and readiness probes:

Docker Swarm

Add a health check to your service definition:

Load Balancers

NGINX

HAProxy

Health Check Response Format

The health check response writer is implemented in src/SharedWeb/Health/HealthCheckServiceExtensions.cs:22. Status Values:
  • Healthy - Service is operating normally
  • Degraded - Service is operational but with issues
  • Unhealthy - Service is not operational
Extended Response Structure:

Troubleshooting

Health Check Fails Immediately

Symptom: /healthz returns 503 or times out Possible Causes:
  1. Identity service is unreachable
  2. Database connection is unavailable
  3. Service hasn’t finished starting up
Resolution:
1

Check Identity Service

Verify the Identity service is running and accessible:
2

Test Database Connection

Verify SQL Server connectivity from the API container:
3

Check Service Logs

Review the API service logs for startup errors:

Intermittent Health Check Failures

Symptom: Health checks occasionally fail even when service appears healthy Common Causes:
  1. Network timeouts between services
  2. Database connection pool exhaustion
  3. Identity service under load
Resolution:
  • Increase health check timeout values
  • Review database connection pool settings in appsettings.json
  • Check Identity service resource allocation

Best Practices

Use Different Endpoints

Use /healthz for liveness probes and /healthz/extended for readiness probes to get appropriate granularity.

Set Appropriate Timeouts

Configure health check timeouts longer than your monitoring interval to avoid false positives.

Monitor Trends

Track health check response times to identify performance degradation before failures occur.

Alert on Patterns

Alert on multiple consecutive failures rather than single failures to reduce noise.