Django HealthCheck

django-health-check gives Django projects a single, extensible endpoint (and management command) that verifies the database, cache, storage, and any registered service dependencies are working, returning a consolidated status instead of requiring a hand-rolled /health view per project. Checks are plugins: the core package ships database/cache/storage backends, and health_check.contrib adds optional checks for Celery, Redis, RabbitMQ, Kafka, and system resources (via psutil), each registered through a plugin registry so unused checks add no overhead.

It’s commonly wired into container orchestration (Kubernetes liveness/readiness probes, load-balancer health checks) or monitoring dashboards that need to know not just that Django is running, but that its dependent services are actually reachable.

What You Get

• A HealthCheckView exposing a JSON/HTML health endpoint that runs all registered checks
• A health_check management command for running checks from the CLI or a cron/liveness probe
• Core backend checks for the database, cache, and file storage out of the box
• Optional health_check.contrib plugins for Celery, Redis, RabbitMQ, Kafka, Atlassian services, and system resource checks via psutil
• A plugin registry (health_check.plugins) for registering custom checks alongside the built-in ones

Common Use Cases

• Wiring a Kubernetes liveness/readiness probe to a Django app’s /health endpoint
• Verifying database, cache, and storage connectivity as part of a deployment smoke test
• Monitoring Celery worker and broker (Redis/RabbitMQ) availability from the same health endpoint as the web app
• Running manage.py health_check in CI or a cron job to catch dependency outages early
• Adding a custom health check plugin for an internal service the application depends on

Under The Hood

Architecture - health_check/base.py defines a BaseHealthCheckBackend interface that every check (core and contrib) implements, health_check/checks.py registers built-in checks, and a plugin registry pattern lets health_check.contrib.* apps register additional backends (Celery, Redis, RabbitMQ, Kafka, psutil) purely by being added to INSTALLED_APPS; views.py aggregates all registered backends’ results into one response and management/commands/health_check.py exposes the same aggregation as a CLI command. Tech Stack - Pure Django app (Python 3.10+, Django 5.2/6.0 per current classifiers) with contrib integrations depending on their respective client libraries (celery, redis, psutil, kafka) only when those contrib apps are installed; packaged with Flit (flit_core/flit_scm) rather than setuptools. Code Quality - 20 test files back the core and contrib checks, with Codecov coverage reporting wired into CI, and the project has stayed continuously active (commits as recently as mid-July 2026) across many Django version upgrades, reflected in its 82/100 repo health score. API Design - Enabling a check is typically just adding an app to INSTALLED_APPS (e.g. health_check.contrib.celery) with no further wiring required for the common cases, which keeps the integration cost low; writing a fully custom check means subclassing BaseHealthCheckBackend and registering it, a small but necessary extra step beyond the built-in checks.