The Django Debug Toolbar ships with a series of built-in panels. In addition, several third-party panels are available.
Default built-in panels¶
The following panels are enabled by default.
Shows versions of Python, Django, and installed apps if possible.
A list of settings in settings.py.
This panels shows the HTTP request and response headers, as well as a selection of values from the WSGI environment.
Note that headers set by middleware placed before the debug toolbar middleware
MIDDLEWARE_CLASSES won’t be visible in the panel. The WSGI server
itself may also add response headers such as
GET/POST/cookie/session variable display.
SQL queries including time to execute and links to EXPLAIN each query.
Templates and context used, and their template paths.
Used static files and their locations (via the staticfiles finders).
List of signals, their args and receivers.
Logging output via Python’s built-in
When this panel is enabled, the debug toolbar will show an intermediate page upon redirect so you can view any debug information prior to redirecting. This page will provide a link to the redirect destination you can follow when ready.
Since this behavior is annoying when you aren’t debugging a redirect, this
panel is included but inactive by default. You can activate it by default with
DISABLE_PANELS configuration option.
Non-default built-in panels¶
The following panels are disabled by default. You must add them to the
DEBUG_TOOLBAR_PANELS setting to enable them.
Profiling information for the processing of the request.
debug_toolbar.middleware.DebugToolbarMiddleware is first in
MIDDLEWARE_CLASSES then the other middlewares’
will not be executed. This is because
HttpResponse which causes the other middlewares’
process_view methods to be skipped.
Note that the quick setup creates this situation, as it inserts
DebugToolbarMiddleware first in
If you run into this issues, then you should either disable the
ProfilingPanel or move
DebugToolbarMiddleware to the end of
MIDDLEWARE_CLASSES. If you do the latter, then the debug toolbar won’t
track the execution of other middleware.
Third-party panels aren’t officially supported!
The authors of the Django Debug Toolbar maintain a list of third-party panels, but they can’t vouch for the quality of each of them. Please report bugs to their authors.
If you’d like to add a panel to this list, please submit a pull request!
See queries made by your Haystack backends.
HTML Tidy or HTML Validator is a custom panel that validates your HTML and displays warnings and errors.
Retrieves and displays information you specify using the
Inspector panel also logs to the console by default, but may be instructed not
This package provides a profiling panel that incorporates output from line_profiler.
This panel tracks memcached usage. It currently supports both the pylibmc and memcache libraries.
Adds MongoDB debugging information.
Trace neo4j rest API calls in your django application, this also works for neo4django and neo4jrestclient, support for py2neo is on its way.
Switch between requests to view their stats. Also adds support for viewing stats for ajax requests.
Browse Sites registered in
django.contrib.sites and switch between them.
Useful to debug project when you use django-dynamicsites which sets SITE_ID
Shows template render call duration and distribution on the timeline. Lightweight. Compatible with WSGI servers which reuse threads for multiple requests (Werkzeug).
Displays template rendering times for your Django application.
Easily switch between logged in users, see properties of current user.
API for third-party panels¶
Third-party panels must subclass
according to the public API described below. Unless noted otherwise, all
methods are optional.
Panels can ship their own templates, static files and views. They’re no public CSS API at this time.
Base class for panels.
Title shown in the side bar. Defaults to
Subtitle shown in the side bar. Defaults to the empty string.
Trueif the panel can be displayed in full screen,
Falseif it’s only shown in the side bar. Defaults to
Title shown in the panel when it’s displayed in full screen.
Mandatory, unless the panel sets
Template used to render
Mandatory, unless the panel sets
Falseor overrides attr:content`.
Content of the panel when it’s displayed in full screen.
By default this renders the template defined by
template. Statistics stored with
record_stats()are available in the template’s context.
Return URLpatterns, if the panel has its own views.
Enable instrumentation to gather data for this panel.
This usually means monkey-patching (!) or registering signal receivers. Any instrumentation with a non-negligible effect on performance should be installed by this method rather than at import time.
Unless the toolbar or this panel is disabled, this method will be called early in
DebugToolbarMiddleware.process_request. It should be idempotent.
Disable instrumentation to gather data for this panel.
This is the opposite of
Unless the toolbar or this panel is disabled, this method will be called late in
DebugToolbarMiddleware.process_response. It should be idempotent.
Store data gathered by the panel.
Each call to
record_statsupdates the statistics dictionary.
Like process_request in Django’s middleware.
Write panel logic related to the request there. Save data with
process_view(request, view_func, view_args, view_kwargs)¶
Like process_view in Django’s middleware.
Write panel logic related to the view there. Save data with
Like process_response in Django’s middleware.
Write panel logic related to the response there. Post-process data gathered while the view executed. Save data with
Triggers the event to close any active panels.
This is a helper function to fetch values stored in the cookies.
- key (string) – The key for the value to be fetched.
This is a helper function to set a value stored in the cookies.
- key (string) – The key to be used.
- value (string) – The value to be set.
- options (Object) – The options for the value to be set. It should contain
Closes any panels and hides the toolbar.
This is the toolbar’s version of jQuery.
Shows the toolbar.