Django Log Files: Where They Are and How to Find Them

Your Django application’s log files are not stored in a single default location. Instead, where they end up depends entirely on how you’ve configured Django’s logging system and, crucially, whether you’re running in development or production. In a typical development setup, logs are printed to the console (your terminal), while in production they are usually written to a file or sent to an external logging service. This article explains exactly where to look, how to configure logging to write to a file, and how to troubleshoot common logging issues.

Understanding Django’s Logging System

Django uses Python’s built-in logging module, which is highly configurable. The framework defines a default logging configuration that you can override in your settings.py file. The key components are:

• Loggers – named entities that your code (or Django itself) calls to record events. For example, django, django.request, or myapp.
• Handlers – determine where the log record goes: console, file, email, etc.
• Formatters – define the layout of the log message (e.g., timestamp, level, message).
• Filters – provide finer control over which records are processed.

By default, Django’s logging configuration sends log records with level DEBUG or higher to the console when DEBUG = True, and to the console with level INFO or higher when DEBUG = False. This means in development you’ll see logs in your terminal, not in a file.

Where Django Writes Logs by Default

If you haven’t customized your logging configuration, here’s what happens in common environments:

• Development (runserver): Logs appear in the terminal where you run python manage.py runserver. They are not written to a file. This includes request logs (e.g., “GET / 200”) and any messages from your code using logging.getLogger(__name__).
• Production (WSGI/ASGI): The default configuration still logs to the console. In a typical deployment (e.g., Gunicorn, uWSGI, or a cloud platform), the console output is captured by the process manager or platform and often stored in its own log files (e.g., systemd journal, Heroku logs, or Docker container logs). For example, if you run Gunicorn, its output (including Django logs) goes to stderr, which you can redirect to a file if you wish.

So, if you’re asking “where are my log files?” and you haven’t set up file logging, the answer is: there are no dedicated log files. The logs are going to the console of whatever process is running your app.

How to Configure Django to Write Logs to a File

To have Django write logs to a specific file, you need to define a LOGGING dictionary in your settings.py. Here’s a minimal example that writes all DEBUG and higher messages to a file named django.log in your project root:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'file': {
            'level': 'DEBUG',
            'class': 'logging.FileHandler',
            'filename': 'django.log',
        },
    },
    'loggers': {
        'django': {
            'handlers': ['file'],
            'level': 'DEBUG',
            'propagate': True,
        },
    },
}

This configuration will create django.log in the directory where you run manage.py (usually your project root). Be aware that the file is created when the first log record is written, not at startup. Also, if the directory is not writable, you’ll get an error.

For production, you’ll likely want to use a more robust handler like logging.handlers.RotatingFileHandler to prevent the file from growing indefinitely. Example:

'class': 'logging.handlers.RotatingFileHandler',
'filename': '/var/log/django/app.log',
'maxBytes': 1024*1024*5,  # 5 MB
'backupCount': 5,

This keeps five backup files (app.log.1, app.log.2, etc.) and rotates when the file reaches 5 MB.

Where to Look for Logs in Common Deployment Setups

If you’re using a specific deployment tool, here are the typical locations for logs (including Django’s output):

• Gunicorn: By default, Gunicorn logs to stderr. If you run it manually, you can redirect to a file: gunicorn myproject.wsgi --error-logfile /path/to/error.log --access-logfile /path/to/access.log. Django’s own logs (if not configured otherwise) go to the error log.
• uWSGI: Similar; use --logto /path/to/uwsgi.log to capture all output.
• systemd: If you run Django as a systemd service, logs are sent to the journal. View them with journalctl -u mydjango.service.
• Docker: Logs go to stdout/stderr, which Docker captures. Use docker logs <container_name> to view them.
• Heroku: Logs are aggregated and viewable with heroku logs --tail.
• Nginx/Apache: These web servers have their own access/error logs, but they don’t contain Django application logs (only HTTP-level errors). Django logs go to the application server’s output.

If you’re using a platform like AWS Elastic Beanstalk or Google App Engine, they typically capture stdout/stderr and make it available via their logging interfaces.

Common Problems and Misconceptions

One frequent misconception is that Django automatically logs to a file like debug.log in the project folder. It does not. Unless you configure it, logs go to the console. Another issue is that you configure a file handler but don’t see any logs because the logger level is too high (e.g., you set INFO but your code logs DEBUG). Also, be aware that disable_existing_loggers: False is important to keep Django’s default loggers active; if you set it to True, you might suppress important messages.

Another common problem is that the log file is not created because the directory doesn’t exist or isn’t writable. For instance, /var/log/django/ might not exist. You need to create it and ensure the user running the app has write permissions. In production, it’s common to use a dedicated log directory like /var/log/ or a subdirectory of your project, but be careful about permissions.

Best Practices for Logging in Django

Here are some practical tips for managing logs effectively:

• Use different loggers for different parts – e.g., django.request for HTTP requests, django.db.backends for SQL queries, and your own app loggers. This lets you route them to different handlers.
• Set appropriate levels – In production, you usually want INFO and above. DEBUG can be noisy and expose sensitive data.
• Rotate log files – Use RotatingFileHandler or TimedRotatingFileHandler to avoid filling up disk space.
• Centralize logs – For multi-server setups, consider sending logs to a central service like ELK (Elasticsearch, Logstash, Kibana) or a cloud logging service. This is often easier than managing files on each server.
• Don’t log sensitive information – Be careful not to log passwords, tokens, or personal data. Use filters to redact if necessary.

Frequently Asked Questions

Why don’t I see any log files in my Django project?

Because by default Django doesn’t create log files. It outputs logs to the console (stderr). If you want files, you must configure the LOGGING setting as shown above.

How do I find the log file if I’m using Gunicorn?

Gunicorn doesn’t write to a file unless you specify --error-logfile or --access-logfile. If you didn’t, logs go to stderr, which is often captured by your process manager (systemd, Docker, etc.). Check those logs.

What is the default log level in Django?

When DEBUG = True, the default level is DEBUG (shows everything). When DEBUG = False, it’s INFO (shows info, warning, error, critical). You can override this in your LOGGING config.

Can I log to multiple places at once?

Yes, you can attach multiple handlers to a logger. For example, you can have a file handler and a console handler, so logs go to both. This is useful in development to see logs in the terminal while also saving them to a file.

How do I view logs in a Docker container?

Use docker logs <container_name> to see the container’s stdout/stderr. If Django is configured to log to a file inside the container, you can use docker exec -it <container_name> cat /path/to/logfile to view it.

What’s the difference between Django logs and web server logs?

Web server logs (Nginx, Apache) record HTTP requests at the server level, including static files and 404s. Django logs record application-level events, such as exceptions, database queries, and custom logging in your code. They are separate and serve different purposes.

Related

• MGS2 Master Collection vs Original: Which to Play?
• AI Agent Runtime Security: Enterprise Buyer Guide
• Encrypted USB Drives vs Secure Cloud Storage for File Transfer