Skip to main content
Logfire for Django

Trace, monitor and debug your Django app

Django Observability from the team behind Pydantic: instrument requests, views and ORM queries, catch production N+1s, and query everything in plain SQL. Standard OpenTelemetry, no lock-in.

Try Logfire for free See the Django docs
Install and configure 
pip install 'logfire[django,psycopg]'
logfire auth   # or set LOGFIRE_TOKEN in production
Instrument your app 
# settings.py, at the very end, after your other settings

import logfire

logfire.configure()
logfire.instrument_psycopg()   # use the integration that matches DATABASES
logfire.instrument_django()    # keep this last

Full details are in the Django setup guide.

Trusted by teams building production software and AI

What you get

One request, one trace

A Logfire trace of a Django request showing an N+1: one query for the order list followed by five near-identical order_items queries, then a 404 request in red

Every request becomes a trace, the full timeline of one request, built from nested spans, each a timed unit of work, for the view and each ORM query. So an N+1, where the code runs one extra query per row instead of one for all of them, shows up as the same query firing thirty times in one trace, impossible to miss.

Try it on your stack

See your own Django trace

Start free with 10 million spans, logs, and metrics each month. No credit card required.

Start free Read the Django setup guide
How it works

Every request, every query, connected

Catch N+1 queries in production

This is where tracing earns its keep for Django. When your ORM query span shows up thirty times inside a single request, each nearly identical, you have found an N+1, and you have found it against real traffic rather than a synthetic local page. The trace shows the problem and confirms the fix once you add select_related or prefetch_related.

Trace views, tasks, and outbound calls

Add the layers a Django app leans on, one line each: logfire.instrument_django(), logfire.instrument_psycopg(), logfire.instrument_requests(), logfire.instrument_celery(), logfire.instrument_redis(). Instrument Celery in the worker process as well as the web process, and a task kicked off by a request stays connected to the trace that started it, so a slow background job is a single readable story.

Trace your own logic

For business operations, open a span where the work begins with logfire.span("checkout", cart_id=cart.id). It becomes the parent of the auto-instrumented queries and calls it triggers, with attributes you can filter and group on.

One query surface for the Django stack

Query request spans, view names, Celery tasks, database timings, metrics, and structured logs in one Logfire project. The same SQL can answer an ad-hoc question first and become a dashboard or alert when it proves useful.

Open standard, no lock-in

Logfire is OpenTelemetry underneath. Standard OpenTelemetry tooling works, and you can export the same telemetry to another backend or self-host without touching your app. You instrument once against the open standard.

Query

Query your Django telemetry with SQL

If you can ask it, SQL can find out

  • Query your traces, metrics and logs with real SQL
  • No proprietary query language to learn
  • AI models are great at writing SQL
  • From a one-off investigation to an alert, dashboard, or SLO
select
  attributes->>'db.statement' as query,
  count(*) as calls,
  sum(duration) as total_seconds
from records
where attributes->>'db.system' = 'postgresql'
group by query
order by total_seconds desc;
Proof

In production

We are finding and fixing issues in five minutes instead of an hour, which is obviously increasing uptime for our clients.
Zach Silver, Staff Software Engineer, BoostedAI Read the case study
Decision guide

Is Logfire right for you?

Choose Logfire if

  • You want to see slow requests and ORM queries in production, not just in local dev
  • You want N+1 query patterns to be obvious against real traffic
  • You want views, Celery tasks, and outbound calls connected in one trace
  • You want to query traces, metrics, and logs with PostgreSQL-compatible SQL
  • You want the portability of OpenTelemetry with Python-first ergonomics

Choose a traditional APM if

  • You are already deeply integrated with a specific APM vendor's ecosystem
  • You need a vendor-only integration or compliance capability Logfire does not offer
  • You only need local development profiling, where the Django Debug Toolbar is enough
FAQ

Common questions

How do I add OpenTelemetry to a Django application?

Install Pydantic Logfire, call logfire.configure() at the very end of settings.py, then logfire.instrument_django() last of all to trace requests and the integration that matches your database driver, such as logfire.instrument_psycopg() or logfire.instrument_sqlite3(), to trace ORM queries. Logfire is OpenTelemetry-native, so standard OpenTelemetry tooling works as well.

Can observability help me find N+1 queries in Django?

Yes, and it is one of the biggest wins. With database instrumentation enabled, a repeated ORM query shows up as many nearly identical spans inside one request trace. That makes N+1 patterns obvious against real production traffic, and the trace confirms the fix once you add select_related or prefetch_related.

Is this different from the Django Debug Toolbar?

Yes. The Django Debug Toolbar is excellent for local development but runs only there. Logfire gives you the same query-level and timing detail in production, across real requests, background tasks, and external calls, with alerting and history.

Does instrumenting Django slow it down?

Auto-instrumentation is designed for production use. Telemetry is batched and exported asynchronously, and traces can be sampled to control volume, so overhead is small compared to the time saved finding slow queries and failing requests.

See your Django app in production

Get started with 10 million free spans, logs, and metrics per month. No credit card required.

Start free Book a demo View pricing plans