Skip to main content
The Health API provides a simple endpoint to check if the PocketBase API is running and healthy.

Health check

Check the health status of the API.
Authentication: Optional (additional info for superusers)

Response

number
HTTP status code (200)
string
Health status message (“API is healthy.”)
object
Additional health information (varies by auth level)

Superuser response fields

When authenticated as a superuser, the response includes additional diagnostic information:
boolean
Whether a backup operation can be started (no backup currently in progress)
string
The detected real IP address of the client
string
The header used to determine the client’s IP, if behind a proxy (e.g., X-Forwarded-For, CF-Connecting-IP, Fly-Client-IP)

Use cases

Basic health monitoring

Use this endpoint to monitor if your PocketBase instance is running:

Load balancer health checks

Configure your load balancer to use /api/health as the health check endpoint:

Docker health checks

Add a health check to your Docker configuration:

Kubernetes liveness probe

Monitoring scripts

Response codes

The health endpoint always returns 200 OK if the server is running. It doesn’t check database connectivity or other subsystems.

Proxy detection

For superusers, the endpoint checks common reverse proxy headers to help identify if the application is deployed behind a proxy:
  • X-Forwarded-For
  • CF-Connecting-IP (Cloudflare)
  • Fly-Client-IP (Fly.io)
  • Custom headers from TrustedProxy.Headers settings
This helps diagnose IP-related issues when using features like rate limiting or geo-based access control.

Performance

The health endpoint is lightweight and doesn’t perform any database queries. It’s safe to call frequently for monitoring purposes. Typical response time: < 1ms

Best practices

  1. Use for uptime monitoring - Regularly ping this endpoint to detect outages
  2. Set appropriate timeouts - Configure health check timeouts (3-5 seconds recommended)
  3. Don’t authenticate - Use as an unauthenticated endpoint for public monitoring
  4. Combine with deep checks - For critical systems, supplement with database connectivity tests

Limitations

The health endpoint only verifies that the HTTP server is responding. It does not check:
  • Database connectivity
  • Storage system availability
  • Background job status
  • Memory or disk space
For comprehensive health monitoring, consider implementing custom health checks that test critical subsystems.

Example monitoring setup

Simple uptime monitor

Advanced monitoring with superuser info