Django Logging: LOGGING Setting, JSON, and Request IDs

Last verified on Nov 8, 2026.

Django configures logging through one setting, LOGGING, which it hands to Python's dictConfig during startup. The defaults are tuned for development: console output when DEBUG is on, and almost nothing useful when it is off. This guide sets up JSON on stdout, per-logger levels controlled by environment variables, and a request ID on every line, then covers what django.request does and does not log.

What Django Logs by Default

The Django reference spells out the defaults. When DEBUG is True, the django logger sends INFO and above to the console. When DEBUG is False, it sends only ERROR and CRITICAL to AdminEmailHandler, which emails the addresses in ADMINS. The django.server logger, used by runserver, always writes INFO and above to the console.

The loggers you will meet most:

Notice what is missing: a production access log. django.request covers 4XX and 5XX only, so successful requests need a log line from your WSGI or ASGI server or from your own middleware.

A Production LOGGING Setting

Set disable_existing_loggers to False. Django's docs warn that when the key is missing it defaults to True, which disables Django's own default loggers so they silently discard everything. They suggest either redefining the defaults you care about or setting LOGGING_CONFIG = None to take over entirely.

# settings.py
import os

LOGGING = {
    "version": 1,
    "disable_existing_loggers": False,
    "filters": {"request_id": {"()": "myproject.logging_utils.RequestIdFilter"}},
    "formatters": {"json": {"()": "myproject.logging_utils.JsonFormatter"}},
    "handlers": {
        "console": {
            "class": "logging.StreamHandler",
            "formatter": "json",
            "filters": ["request_id"],
        },
    },
    "root": {"handlers": ["console"], "level": "WARNING"},
    "loggers": {
        "django": {
            "handlers": ["console"],
            "level": os.getenv("DJANGO_LOG_LEVEL", "INFO"),
            "propagate": False,
        },
        "myapp": {
            "handlers": ["console"],
            "level": os.getenv("APP_LOG_LEVEL", "INFO"),
            "propagate": False,
        },
    },
}

The "()" key is dictConfig's way to build a custom class from a dotted path. StreamHandler with no stream writes to stderr, which container platforms capture the same way as stdout. Pick whichever your platform treats as a normal log. Name your own loggers with logging.getLogger(__name__) in each app so myapp.orders inherits from myapp. See log levels for how to choose between INFO and WARNING.

The Formatter and Filter

The formatter turns each record into one JSON object. It skips the request attribute that django.request attaches, because dumping a request object is noisy and can include headers you did not mean to log:

# myproject/logging_utils.py
import contextvars
import json
import logging
from datetime import datetime, timezone

request_id_var = contextvars.ContextVar("request_id", default=None)

_STANDARD = set(logging.LogRecord("", 0, "", 0, "", (), None).__dict__) | {
    "message", "asctime", "taskName",
}
_SKIP = {"request"}


class RequestIdFilter(logging.Filter):
    def filter(self, record):
        record.request_id = request_id_var.get()
        return True


class JsonFormatter(logging.Formatter):
    def format(self, record):
        payload = {
            "timestamp": datetime.fromtimestamp(record.created, timezone.utc).isoformat(),
            "level": record.levelname,
            "logger": record.name,
            "message": record.getMessage(),
        }
        for key, value in record.__dict__.items():
            if key not in _STANDARD and key not in _SKIP and value is not None:
                payload[key] = value
        if record.exc_info:
            payload["exception"] = self.formatException(record.exc_info)
        return json.dumps(payload, default=str)

Anything passed through extra shows up as a field, along with status_code from the request loggers. The Python logging guide explains this formatter in more detail, and the JSON logging guide covers field naming. If you would rather keep keyword-style logging, the structlog guide shows how to route Django's records through structlog.

Add a Request ID With Middleware

Set the ID when the request enters, and the filter attaches it to every record logged afterward, including from libraries:

import uuid
from .logging_utils import request_id_var


class RequestIdMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        rid = request.headers.get("X-Request-ID") or str(uuid.uuid4())
        request_id_var.set(rid)
        response = self.get_response(request)
        response["X-Request-ID"] = rid
        return response

Add it first in MIDDLEWARE. Output looks like this:

{"timestamp": "2026-11-08T06:48:14.894559+00:00", "level": "INFO", "logger": "myapp.orders", "message": "order placed", "order_id": 4812, "request_id": "req-8f3a"}
{"timestamp": "2026-11-08T06:48:14.895387+00:00", "level": "WARNING", "logger": "django.request", "message": "Not Found: /missing/", "status_code": 404, "request_id": "req-9b21"}

Returning the ID in a response header lets a user or a front-end team quote it in a bug report, and it is the same value you search for as a correlation ID.

Do not reset the context variable in a finally block after the response. Django logs some django.request records, such as a 4XX response a view returns, after the middleware chain returns, and those records would come out with no request_id. Leaving the variable set until the next request overwrites it avoids that. On ASGI each request runs in its own context, so there is nothing to leak.

Common Mistakes

• Missing disable_existing_loggers: False. Django's own loggers go quiet, and a 500 leaves no trace.
• Using print or a bare logging.basicConfig in settings. LOGGING is merged with Django's defaults, so a second configuration fights it.
• Expecting SQL logs in production. The django.db.backends logger only emits when DEBUG = True, regardless of level or handlers.
• Leaving DEBUG = True on a deployed host. It also switches on SQL query logging, which Django limits to DEBUG for performance reasons.
• Logging whole request or user objects. Pass IDs, not objects.
• Relying on AdminEmailHandler as monitoring. Email on every ERROR does not scale past a few errors an hour.

Production Tips

• Keep django at INFO or WARNING and set it with an environment variable so you can raise it for one deploy without a code change.
• Send to stdout or stderr and let the platform forward it. Do not manage log files inside the container.
• Log the user ID or tenant ID on each request in the same middleware, next to request_id.
• Read logging best practices for what to put in a log line and what to keep out.

Sending Django Logs to Sazabi

Sazabi, an AI-native observability and security platform, accepts logs and traces over OTLP/HTTP. Its OpenTelemetry source docs describe starting a Python app under opentelemetry-instrument with OTEL_EXPORTER_OTLP_ENDPOINT set. The OpenTelemetry Python configuration reference lists OTEL_PYTHON_DJANGO_INSTRUMENT, which is enabled by default, so request spans appear without code changes, and OTEL_PYTHON_LOG_CORRELATION for putting trace context into log records. Your JSON console handler can stay as it is. See the OpenTelemetry Python guide, the OpenTelemetry integration, and client errors for watching the 4XX stream that django.request produces.