django-log-request-id

What it is and what it does

django-log-request-id is a Django middleware and logging filter that generates or extracts a unique identifier for each HTTP request and injects it into every log message produced during that request's lifecycle. The ID is stored in a ContextVar and automatically included in log output, allowing developers to grep or search logs to isolate all messages from a single request—essential for debugging high-traffic applications where logs from many concurrent requests are interleaved.

The package supports several configuration options: it can use a request ID from an incoming HTTP header (such as X-Request-Id from load balancers or proxies like Heroku), fall back to generating one if the header is missing, add the ID to the HttpRequest object for use in views, and optionally include it in response headers. It can also log all incoming requests with metadata like user ID. Setup requires adding the middleware to Django's MIDDLEWARE list and configuring a logging filter and formatter to include the request_id variable in log output.

Use it for:

• Debugging multi-step request flows in high-traffic applications by searching logs for a single request ID across multiple modules and layers.
• Correlating logs from load balancers or proxies that generate their own request IDs with application-level logs.
• Building request tracing without a full distributed tracing system by embedding request IDs in application logs.
• Auditing user actions by logging all operations tied to a specific request ID.
• Monitoring and alerting on specific request patterns by filtering logs by request ID in log aggregation tools.

Worth the install?

AI-flagged interpretation of the facts on this page — verify before relying

Attaches a unique request ID to every log message generated during a Django HTTP request, enabling you to trace all logs from a single request across your application.

Yes. The package is actively maintained, has no known vulnerabilities, low install friction (one Django dependency), and solves a genuine debugging problem in Django applications. The permissive BSD-3-Clause license poses no barrier. The only caveat is that it relies on ContextVar, which the documentation acknowledges is unconventional for Django but is the only viable approach—verify compatibility with your specific Django version and async usage patterns if applicable.

Install

django-log-request-id on PyPI

pip install django-log-request-id

uv add django-log-request-id

poetry add django-log-request-id

Installing django-log-request-id

Before you install

Low friction: pure Python wheel with only django as a runtime dependency. Actively maintained with a recent release (155 days ago) and no known vulnerabilities.

License in practice

BSD-3-Clause permissive license allows use in most commercial and open-source projects with minimal restrictions—retain copyright notice and disclaimer.

Quickstart

pip install django-log-request-id

# In settings.py:
MIDDLEWARE = [
    'log_request_id.middleware.RequestIDMiddleware',
    # ...
]

# In logging config:
LOGGING = {
    'filters': {'request_id': {'()': 'log_request_id.filters.RequestIDFilter'}},
    'formatters': {'standard': {'format': '[%(request_id)s] %(message)s'}},
    'handlers': {'console': {'filters': ['request_id'], 'formatter': 'standard', 'class': 'logging.StreamHandler'}},
}

# Then log normally:
import logging
logger = logging.getLogger(__name__)
logger.debug("Message with request ID attached")

Requires Django and Python >= 3.10; request ID is stored in a ContextVar, which the documentation notes is not standard Django practice but is the only viable approach for this use case.

Verify before relying

• Whether ContextVar-based storage has measurable performance impact in high-concurrency scenarios.
• Compatibility with async Django views and async middleware.
• Whether the package works with Django versions older than those in current support.

Package facts

Evidence: django_log_request_id-2.1.2-py3-none-any.whl

Tags

More Dynamic Content packages