OpenTelemetry-native observability for FastAPI, from the team that makes Pydantic. One line instruments every route, and each request shows its dependencies, database queries, and Pydantic validation in one connected trace. Free for 10 million spans a month.
pip install 'logfire[fastapi]'import logfire
from fastapi import FastAPI
logfire.configure()
app = FastAPI()
logfire.instrument_fastapi(app)That single call captures every request: the route, method, status code, timing, the validated arguments, and any exception. Because Logfire wraps OpenTelemetry's ASGI instrumentation, it understands the async request lifecycle correctly.
Every request becomes a trace, the full timeline of one request, built from nested spans, each a timed unit of work, from the route down to each query, validation, and outbound call, with timing and errors attached.
The route span is the start. Add the libraries the endpoint uses, one line each: logfire.instrument_sqlalchemy(), logfire.instrument_asyncpg(), logfire.instrument_httpx(), logfire.instrument_redis(). A request to POST /orders then shows the incoming call, the Pydantic validation, each database query with its timing, and the outbound call to your payments provider. When something is slow, you can see which part.
FastAPI request bodies are Pydantic models, and instrument_fastapi already captures the validated arguments and validation errors: a malformed request shows the model, the input, and the exact field that failed, turning a vague wave of 422s into a specific, fixable cause. For models you validate outside the endpoint signature, add logfire.instrument_pydantic() to trace those too. Captured arguments can include request data, so note that Logfire scrubs common sensitive fields by default and the scrubbing rules are configurable.
For the business logic inside a handler, open a span where the real work begins with logfire.span("create_order", customer=order.customer_id). It becomes the parent of the auto-instrumented queries and HTTP calls it triggers, with customer_id captured as a queryable attribute.
Logfire is not just tracing. Send metrics and structured logs alongside your traces, build dashboards, and set alerts, all in the same OpenTelemetry-native project, and query all of it with the same SQL.
Logfire is OpenTelemetry underneath. Your FastAPI instrumentation is portable: send the same data to another OTel backend or self-host, and nothing in your app changes. You instrument once against the open standard and keep your options open.
select
attributes->>'http.route' as route,
count(*) as requests,
avg(duration) as avg_seconds
from records
where http_response_status_code >= 500
group by route
order by requests desc;Your traces, metrics, and logs are queryable with real SQL, no proprietary query language to learn. Any question you can express becomes a dashboard, an alert, or a one-off investigation.
| Approach | Strengths | Trade-offs |
|---|---|---|
| Datadog / New Relic | Deep, mature APM | Proprietary, pricing climbs at scale |
| Sentry | Strong error tracking | Lighter on tracing and performance detail |
| Prometheus + Grafana | Great metrics | You assemble tracing and logs separately |
| Raw OpenTelemetry + DIY backend | Portable and open | You run the backend yourself |
| Pydantic Logfire | One-line FastAPI setup, Pydantic-aware, SQL, hosted | Python and OTel-first, so a weaker fit for non-Python stacks; hosted by default, and younger than the incumbents |
Install Pydantic Logfire, call logfire.configure(), then logfire.instrument_fastapi(app). That one line captures every route, request, response, and exception. Add instrument_sqlalchemy(), instrument_httpx(), and similar to trace the database and outbound calls each request makes. Logfire is OpenTelemetry-native, so standard OTel tooling works too.
Yes. FastAPI validates requests with Pydantic, and because Logfire is built by the Pydantic team, calling logfire.instrument_pydantic() surfaces validation as spans. A failed request shows the model, the input, and the exact field that did not match, so a wave of 422s becomes a specific, fixable cause.
Set the standard OpenTelemetry variable OTEL_PYTHON_FASTAPI_EXCLUDED_URLS to a comma-separated list, for example health,metrics. Those routes are then skipped, keeping your traces focused on real traffic.
Auto-instrumentation is built for production. Telemetry is batched and exported asynchronously, and traces can be sampled to control volume, so the runtime cost is small relative to the visibility gained into slow endpoints and failing calls.
Get started with 10 million free spans per month. No credit card required.