{"slug": "django-deploy-probes-deployment-probe-endpoints-for-django", "title": "django-deploy-probes — deployment probe endpoints for Django", "summary": "The article introduces **django-deploy-probes**, a small Django package that provides standardized health check endpoints (`/healthz`, `/readyz`, `/startupz`, `/version`) for production deployment workflows like Kubernetes probes and Docker health checks. It separates lightweight liveness checks from dependency checks (e.g., database, Redis) by design, placing the latter in `/readyz` or `/startupz` to avoid mixing concerns. The package aims to replace the inconsistent, repeatedly rewritten health check logic found across Django projects with a reusable, simple solution.", "body_md": "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.\n\nI built `django-deploy-probes`\n\nto make that cleaner.\n\nIt is a small Django package that adds these endpoints:\n\n`/healthz`\n\n`/readyz`\n\n`/startupz`\n\n`/version`\n\nThe 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.\n\nOne design choice I cared about was keeping `/healthz`\n\nlightweight. 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`\n\nor `/startupz`\n\nand be enabled explicitly through settings.\n\nThe 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.\n\nInstallation is simple:\n\n```\npip install django-deploy-probes\n```\n\nThen include the URLs in your Django project:\n\n``` python\nfrom django.urls import include, path\n\nurlpatterns = [\n    path(\"probes/\", include(\"django_deploy_probes.urls\")),\n]\n```\n\nThat gives you endpoints like:\n\n- /probes/healthz\n- /probes/readyz\n- /probes/startupz\n- /probes/version The first public release is 0.1.0, and it is available on both GitHub and PyPI.\n\nGitHub: [https://github.com/emfpdlzj/django-deploy-probes](https://github.com/emfpdlzj/django-deploy-probes)\n\nPyPI: [https://pypi.org/project/django-deploy-probes/](https://pypi.org/project/django-deploy-probes/)\n\nI’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.", "url": "https://wpnews.pro/news/django-deploy-probes-deployment-probe-endpoints-for-django", "canonical_source": "https://dev.to/emfpdlzj/django-deploy-probes-deployment-probe-endpoints-for-django-5akb", "published_at": "2026-05-24 04:26:25+00:00", "updated_at": "2026-05-24 05:02:15.456778+00:00", "lang": "en", "topics": ["developer-tools", "open-source", "cloud-computing"], "entities": ["Django", "django-deploy-probes", "Kubernetes", "Docker", "GitHub", "PyPI"], "alternates": {"html": "https://wpnews.pro/news/django-deploy-probes-deployment-probe-endpoints-for-django", "markdown": "https://wpnews.pro/news/django-deploy-probes-deployment-probe-endpoints-for-django.md", "text": "https://wpnews.pro/news/django-deploy-probes-deployment-probe-endpoints-for-django.txt", "jsonld": "https://wpnews.pro/news/django-deploy-probes-deployment-probe-endpoints-for-django.jsonld"}}