Disable HTTP access logs in Python web applications

Change the logger or server setting that produces the access record. Flask's development server uses werkzeug; Django's runserver uses django.server; Uvicorn has a dedicated access-log switch. Application error logs may follow a different route.

Flask's development server

import logging
from flask import Flask

app = Flask(__name__)
logging.getLogger("werkzeug").setLevel(logging.ERROR)

This drops lower-severity Werkzeug records while retaining ERROR and CRITICAL records. Changing app.logger alone does not silence Werkzeug's access records. In production, configure the WSGI server or reverse proxy that actually writes them.

Django

For the development server, merge this logger entry into your existing LOGGING configuration:

LOGGING = {
    "version": 1,
    "disable_existing_loggers": False,
    "handlers": {
        "request_console": {"class": "logging.StreamHandler"},
    },
    "loggers": {
        "django.server": {
            "level": "ERROR",
            "propagate": False,
            "handlers": ["request_console"],
        },
    },
}

This example explicitly defines its handler because dictionary configuration rebuilds the handler configuration. Merge it with the other handlers, formatters, and logger entries your application needs; do not assume a handler from Django's earlier default configuration will remain available by name. django.request records request-handling problems, including warning and error responses; it is not the general access logger for every successful request. Do not disable it just to remove routine access lines.

FastAPI and Uvicorn

Disable only access logging when starting the server:

uvicorn main:app --no-access-log

Or, when app is your ASGI application:

import uvicorn
uvicorn.run(app, access_log=False)

Raising the uvicorn.access level to WARNING also suppresses its normal INFO access records, but startup logging configuration can override an earlier logger change. The server option makes the intent explicit.

Keep useful diagnostics

Before removing access records, check whether they are needed for traffic analysis or incident investigation. Filtering health checks or applying a deliberate sampling policy may be more useful than suppressing every request. Send retained records to your log collector with the application's error logs.

FAQ

Will errors still be recorded? Verify this with a failing request. Uvicorn separates access and error logging, while a single development-server logger can contain several severities. Raising its threshold also removes lower-severity diagnostic messages.

What about Gunicorn? Its accesslog setting defaults to Python None, which disables the access log. Remove an overriding access-log destination or set accesslog = None in its Python configuration. Passing the string None as a filename is not equivalent. Leave its error-log configuration intact.

Can I exclude only certain paths? Attach a filter to the access handler using the actual fields supplied by that server, or configure a matching Nginx location with access_log off. A framework-specific record layout should not be assumed to work across servers.

References

• flask.palletsprojects.com documentation
• docs.djangoproject.com documentation
• www.uvicorn.org documentation
• gunicorn.org documentation