---
title: Django Observability with OpenTelemetry | Pydantic Logfire
description: >-
  Instrument Django with OpenTelemetry in one line. Trace every request, view,
  and ORM query with Logfire, catch N+1 queries, and query it all with SQL.
canonical: 'https://pydantic.dev/logfire/django'
---

> Markdown version of [Trace, monitor and debug your Django app](https://pydantic.dev/logfire/django) — the canonical HTML page.
>
> Site index: [/llms.txt](https://pydantic.dev/llms.txt)

---

# Trace, monitor and debug your Django app

Logfire for Django

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](https://logfire.pydantic.dev/login?intent=signup) [See the Django docs](https://pydantic.dev/docs/logfire/integrations/web-frameworks/django/)

Set up Logfire with your coding agent:

uvx logfire-cli wizard

Install and configure

```bash
pip install 'logfire[django,psycopg]'
logfire auth   # or set LOGFIRE_TOKEN in production
```

Instrument your app

```python
# 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](https://pydantic.dev/docs/logfire/integrations/web-frameworks/django/).

Trusted by teams building production software and AI

**Customers:** Motorola, Sophos, Airbyte, Pictet, Vox Media, Weaviate, Amboss, Tiger Data

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](https://pydantic.dev/assets/logfire/language-traces/django-trace.png)

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](https://logfire.pydantic.dev/login?intent=signup) [Read the Django setup guide](https://pydantic.dev/docs/logfire/integrations/web-frameworks/django/)

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

```sql
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](https://pydantic.dev/case-studies/boostedai)

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](https://logfire.pydantic.dev/login?intent=signup)
* [Book a demo](https://pydantic.dev/contact)
* [View pricing plans](https://pydantic.dev/pricing)
