django-silk: request and SQL profiling inside a running Django app

What django-silk records that a log line does not

A Django view that feels slow in production usually leaves you with a timestamp and a status code. django-silk answers the next question: which queries did this request run, how long did each take, and which line of code issued it. The README describes it as "a live profiling and inspection tool for the Django framework" that "intercepts and stores HTTP requests and database queries before presenting them in a user interface for further inspection".

The intended reader is a Django developer working on their own application, not an operator watching a fleet. The project's classifiers list the intended audience as developers, and the install path assumes you can edit settings.py, urls.py and run manage.py migrate on the app you are debugging. If you cannot change the application's settings or run migrations against its database, django-silk is not the tool you are looking for.

The four pieces: middleware, SQL wrapper, profiler decorator, UI

The README breaks the project into four parts. A middleware intercepts requests and responses. A wrapper around SQL execution profiles database queries. A context manager and decorator profile blocks of code and functions, either manually or dynamically. A user interface presents all of it.

The data flow is straightforward and worth stating plainly: the middleware sits in the request path, request and response metadata plus query records are written to the configured database, and the UI reads them back. Because storage is your application's database, the profiling data lives next to your application data and is subject to the same backup, migration and retention rules. That is convenient for a local setup and awkward for a shared staging database that other people also use.

For each request the README says Silk records time taken, number of queries, time spent on queries, request and response headers, and request and response bodies. Clicking into a request shows the individual queries, and the query table can be sorted by column header. The profile page is separate: it appears when SILKY_PYTHON_PROFILER is enabled, and it uses Python's built-in cProfile.

Installing django-silk and reaching the UI for the first time

Install the package into your virtualenv. The README gives the plain form and an extra that pulls in optional formatting of Python snippets:

pip install django-silk

pip install django-silk[formatting]

The formatting extra installs autopep8, which the setup.py extras_require block lists under the key 'formatting'. Without it the UI still works; you lose the snippet formatting.

Now edit settings.py. Three edits are required. Add the middleware, add the request context processor to your template options, and add silk to INSTALLED_APPS:

MIDDLEWARE = [
    ...,
    'silk.middleware.SilkyMiddleware',
    ...,
]

TEMPLATES = [{
    ...,
    'OPTIONS': {
        'context_processors': [
            ...,
            'django.template.context_processors.request',
        ],
    },
}]

INSTALLED_APPS = (
    ...,
    'silk'
)

Wire the URLs in urls.py. The include uses the namespace 'silk', and the path prefix in the README example is 'silk/':

urlpatterns += [path('silk/', include('silk.urls', namespace='silk'))]

Then create the tables and collect the static assets the UI needs:

python manage.py migrate

python manage.py collectstatic

Start the server and visit /silk/. The README states that Silk begins intercepting requests automatically, so the first page load you perform after this point should already appear in the request list. You do not need to enable anything else to see request-level data; the Python profiler is a separate opt-in.

Turning on cProfile, and the Python 3.12 concurrency limit

Request and query capture is on by default once the middleware is installed. Function-level profiling is not. Set SILKY_PYTHON_PROFILER to True and each request is profiled separately, with output shown on the request's Profiling page:

SILKY_PYTHON_PROFILER = True

If you also want a binary .prof file on disk, set SILKY_PYTHON_PROFILER_BINARY to True. The README says that with this enabled a graph visualisation generated with gprof2dot and viz.js appears on the profile detail page. gprof2dot is a hard dependency in setup.py, pinned at gprof2dot>=2017.09.19, so it is installed whether or not you use the graph.

There is a constraint here that the README states directly and that matters more than any feature list. As of Python 3.12, cProfile cannot run concurrently, so django-silk under Python 3.12 and later will not profile if another profile is running, including its own profiler in another thread. On Python 3.12 and above, expect profiler output to be missing for some requests under concurrent load, and do not read a blank profile page as a bug in your view. This is a property of cProfile, not a django-silk setting you can tune away.

Sampling, path exclusion and the cost of storing every request

The README's configuration section carries entries for recording a fraction of requests, ignoring specific paths, limiting request and response data, clearing logged data, and meta-profiling. That list is the honest description of the project's operating cost. Storing every request and every query means writing rows on the request path, and the settings exist to cut that volume down.

This is the case where django-silk is the wrong tool. If you want continuous visibility into a production service, a middleware that writes to your application database on every request is a poor fit, and the README's own sampling and path-ignoring options are an admission of that. Use them, or keep django-silk out of production entirely. The same applies to request and response bodies: the README lists a setting for limiting request/response data, which implies that capturing full bodies by default is something you may not want on endpoints that handle credentials or personal data.

Middleware ordering is a second practical trap. The README warns that if any middleware placed before silk.middleware.SilkyMiddleware returns a response without invoking its get_response, SilkyMiddleware will not run. Requests that bypass it simply will not appear, and the absence is silent. Separately, if you use django.middleware.gzip.GZipMiddleware, it must be placed before SilkyMiddleware or you get an encoding error.

django-silk compared with Django Debug Toolbar

The obvious alternative is Django Debug Toolbar, and the difference is in where the data goes. Debug Toolbar renders a panel into the response of the page you are looking at. It is tied to that request and that browser view, and it does not persist a history you can filter later.

django-silk stores requests and queries in the database and serves them from a separate UI at /silk/. You can come back to a request after the fact, sort the query table by execution time, and look at requests triggered by something other than a browser page load, such as an API call from a client. That persistence is the whole point, and it is also the cost: database rows accumulate until you clear them, and the middleware runs on the request path rather than only when a debug panel is rendered.

If your question is "why is this one page slow right now", Debug Toolbar answers it with less setup. If your question is "which requests are issuing the most queries, and what did that endpoint do ten minutes ago when a client called it", the stored-request model is what you need.

Maintenance, licence and what an upgrade actually involves

django-silk is a Jazzband project. The last push to the default branch was on 2026-09-12, and the most recent release listed is 5.6.0, tagged the same day. The repository is not archived. Releases before that are 5.5.2 on 2026-08-13 and 5.5.1 on 2026-08-10, so the project ships fixes on a short cycle.

The licence is MIT, declared in setup.py as 'MIT License' and shown in the repository's LICENSE file. MIT is permissive: you can use, modify and redistribute the code, including in closed-source products, provided the copyright notice and licence text are retained. That is the general shape of the licence, not legal advice for your situation.

Upgrade cost is dominated by the database, not the Python package. django-silk ships migrations, and the install instructions include python manage.py migrate. Each upgrade that changes the models means running migrations against whatever database holds the Silk tables. If you have been running django-silk against a production database, that is a migration you have to schedule on a table that grows with traffic. The Python side is lighter: setup.py requires Django>=5.2 and python_requires='>=3.10', and the tested matrix in the README covers Django 5.2, 6.0 and 6.1 on Python 3.10 through 3.15. An application still on an older Django cannot install the current release at all, because the dependency floor is enforced at install time.

Editorial conclusion

Adopt django-silk if you need to see which queries a specific Django view issues and how long each one takes, and you can run it against a development or staging database. Do not adopt it as an always-on production monitor: every intercepted request writes rows, and the README's own settings for sampling, ignored paths and data limits exist because that cost is real. Before rolling it out, verify that SilkyMiddleware sits after any middleware that can short-circuit a response, that GZipMiddleware is placed before it, and that the database user has rights to run the migrations the app ships.

Frequently asked questions

Official sources

1. Issues
2. jazzband/django-silk on GitHub
3. License: MIT
4. README
5. Releases