When deploying Django applications, I kept running into the same problem: health check endpoints were implemented differently in every project, and liveness checks often got mixed together with dependency checks.
I built django-deploy-probes
to make that cleaner.
It is a small Django package that adds these endpoints:
/healthz
/readyz
/startupz
/version
The package is meant for production deployment workflows such as Docker health checks, Kubernetes liveness/readiness/startup probes, blue-green deployments, rolling deployments, and CI/CD deployment validation.
One design choice I cared about was keeping /healthz
lightweight. Database, Redis, Celery, or other dependency checks do not belong in a liveness endpoint by default, so those checks are meant to live in /readyz
or /startupz
and be enabled explicitly through settings.
The goal was not to build a full monitoring system, but to provide a small, reusable package for a piece of deployment logic that tends to get rewritten over and over in Django projects.
Installation is simple:
pip install django-deploy-probes
Then include the URLs in your Django project:
from django.urls import include, path
urlpatterns = [
path("probes/", include("django_deploy_probes.urls")),
]
That gives you endpoints like:
- /probes/healthz
- /probes/readyz
- /probes/startupz
- /probes/version The first public release is 0.1.0, and it is available on both GitHub and PyPI.
GitHub: https://github.com/emfpdlzj/django-deploy-probes
PyPI: https://pypi.org/project/django-deploy-probes/
I’d appreciate feedback from people running Django in production, especially around the endpoint split, default behavior, and whether there are deployment cases I should support better.