Guides / DEBUG = True in production: how to check and fix it

Peter van Doorn Django Cloud · Checked against Django 4.2 and newer, October 2026

DEBUG = True in production: how to check and fix it

If your live site shows a yellow error page with your settings and code when something breaks, DEBUG is on in production. Django's own check says it plainly: security.W018: You should not have DEBUG set to True in deployment. It's one of the most serious Django mistakes, and an easy one to fix and to prevent.

What it means

DEBUG = True is for development. In production it:

• Leaks information. Error pages show tracebacks, local variables, your settings (Django hides settings whose names look secret, but not all) and the URL structure of your site.
• Leaks memory. Django stores every SQL query it runs in memory. A long-running process grows until it is killed.
• Turns off safety checks. ALLOWED_HOSTS is not enforced strictly, and static files are served without the production setup.

How to tell if it's on

1. Open a URL that doesn't exist, such as /this-does-not-exist-123. With DEBUG = True you see a page listing "Using the URLconf defined in ..." and the URL patterns. With DEBUG = False you see a plain "Not Found".
2. Run python manage.py check --deploy on the server; it prints security.W018.
3. Print it from the running environment: python manage.py shell -c "from django.conf import settings; print(settings.DEBUG)".

Why it happens

1. DEBUG = True is hardcoded in settings.py (the startproject default) and nobody changed it.
2. The environment variable is read wrongly. os.environ.get("DEBUG", False) returns the string "False", which is truthy, so debug stays on. See environment variables not read.
3. The wrong settings file runs in production (local.py instead of production.py).
4. Someone turned it on to debug a problem and never turned it off.

The fix

Make the safe value the default and require a deliberate opt-in for debug:

# settings.py
import os

DEBUG = os.environ.get("DJANGO_DEBUG", "").strip().lower() in {"1", "true", "yes", "on"}

Set DJANGO_DEBUG=1 only on your own machine. Production doesn't set it, so it's off. Then redeploy (or restart) and re-run the checks above.

Turning debug off exposes problems it was hiding. Make sure ALLOWED_HOSTS is set, static files are served (static files guide), and you can see errors (500 with DEBUG = False).

If your secrets were ever shown on a public debug page, assume they leaked: rotate SECRET_KEY, database passwords and API keys.

Making it stick in production

• Run python manage.py check --deploy --fail-level WARNING in CI or at the start of every release, so a bad value stops the deploy (deployment checklist).
• Add a test that asserts DEBUG is false under your production settings module.
• Debug production problems with logs and an error tracker, not by flipping DEBUG.

Or skip it

On Django Cloud your settings are stored encrypted and applied per release, so DEBUG is whatever you set it to for that release, and a rollback brings back that release's settings.

pip install djangocloud-cli
djangocloud deploy

Get startedSee pricing

Free plans are available for students, AWS Activate startups, open-source, non-profit and research projects. See how Django Cloud compares with other ways to host Django.

Django is a registered trademark of the Django Software Foundation. Django Cloud is not affiliated with or endorsed by it. Found a mistake in this guide? Tell us and we will fix it.