Keeping it running
Logs, errors, metrics, uptime, backups, and the runbooks you need before the first incident.
This path builds the operational side of a Django site: logging and log rotation, error tracking, health checks, uptime and certificate expiry alerts, metrics, backups with point-in-time recovery and tested restores, disaster recovery, observability, and incident response.
Visibility comes first, then the ability to recover. By the end you will know when something breaks and how to put it back.
The steps
- Django Logging Setup for Production
A default Django project does not give you a production-safe logging setup.
- How to Rotate Django and Gunicorn Logs on Linux
Django and Gunicorn log rotation becomes a production issue as soon as your app writes request logs, error logs, or application logs to disk for more than a few days.
- Set Up Sentry Error Monitoring for Django
Local logs are not enough once a Django app is in production. Exceptions can happen after deploys, during background jobs, or only under real user traffic patterns.
- How to Build a Django Health Check Endpoint for Deployments
A production Django deployment needs a reliable way to answer a simple question: is this instance safe to keep running and safe to receive traffic?
- Set Up Uptime Monitoring and Alerts for Django
Set up external uptime monitoring for Django: what to check, health endpoints, keyword and SSL checks, heartbeats for jobs, and alert routing.
- Monitor TLS Certificate Expiry for Django Sites
Catch expiring HTTPS certificates before users do: check expiry from outside with uptime monitors, Prometheus blackbox exporter, or a scheduled script, cover every domain and certificate path, alert at 21 and 7 days, and verify that renewal actually reloads Nginx.
- Monitor Django with Prometheus and Grafana
Expose Django metrics to Prometheus, handle Gunicorn multiprocess mode, add database and host exporters, build Grafana panels, and alert on what matters.
- Backup and Restore PostgreSQL for Django Apps
A Django app is only recoverable if its PostgreSQL data is recoverable. In production, that means more than occasionally running pg_dump.
- PostgreSQL Point-in-Time Recovery for Django
Set up point-in-time recovery for a Django PostgreSQL database with pgBackRest: WAL archiving, full and incremental backups, restoring to a timestamp before a bad migration, and managed-service PITR.
- Test a Full PostgreSQL Restore for a Django App
Prove your Django backups work by restoring them regularly: automate a restore into a scratch database, measure restore time against your RTO, verify row counts and run Django checks and smoke tests, test point-in-time recovery, and record the results.
- Write a Disaster Recovery Plan for a Django App
Write a practical disaster recovery plan for Django: RPO and RTO targets, failure scenarios, point-in-time recovery, runbooks, access, and drills.
- Django Observability Checklist: Logs, Metrics, Traces, and Alerts
A checklist for observability of a production Django system: structured logs with request IDs, RED metrics for web and Celery, distributed tracing, error tracking, database and queue visibility, SLO-based alerts, dashboards per service, and runbooks linked from alerts.
- Django Incident Response Runbook
A runbook for Django production incidents: declare and assign roles, triage with a fixed checklist across proxy, app, workers, database, and cache, mitigate first, communicate, and run a blameless review.