django-deploy-probes: lightweight health/readiness/startup/version endpoints for Django deployments

Show & Tell
1

Hi everyone,

I released `django-deploy-probes` v0.1.0, a small Django package for runtime deployment probe endpoints.

It adds:

- `/healthz` for lightweight liveness checks

- `/readyz` for dependency readiness checks

- `/startupz` for startup/bootstrap checks, such as pending migrations

- `/version` for deployed service metadata

The package is focused on deployment validation workflows rather than full monitoring. Typical use cases are Docker health checks, Kubernetes probes, blue/green deployments, rolling deployments, and CI/CD deployment gates.

PyPI:

GitHub:

Basic Usage:

INSTALLED_APPS = [
    "django_deploy_probes",
]

from django.urls import include, path

urlpatterns = [
    path("", include("django_deploy_probes.urls")),
]

Example settings:

DEPLOY_PROBES = {
    "SERVICE_NAME": "my-django-app",
    "ENVIRONMENT": "prod",
    "VERSION": "1.2.0",
    "READY_CHECKS": ["database", "redis", "celery"],
    "STARTUP_CHECKS": ["migrations"],
    "DETAIL_LEVEL": "none",
    "EXPOSE_CHECK_MESSAGES": False,
}

A few design choices:

  • /healthz intentionally does not touch the database, Redis, Celery, cache, or external services.
  • /readyz only checks dependencies that are explicitly enabled.
  • Custom check messages are hidden by default to avoid leaking sensitive details.
  • X-Forwarded-For is not trusted by default; security checks use REMOTE_ADDR.

I would appreciate feedback from people running Django in production, especially on:

  • whether the default settings are practical
  • whether the endpoint behavior matches common deployment expectations
  • whether the security options are enough for real internal/public probe setups
  • what checks would be useful in a future 0.2.x

Thanks.

1 Like