Skip to main content

Observe

AI observability that traces below the model call

Trace every LLM call, tool invocation, and database query in one place, from local dev to production. Free for 10 million records a month.

Send your first trace Start free Read the docs
The Logfire live view for the acme organization. Two trace rows, an agent run and a chat gpt-5 call, both taking 12.2 seconds on pydantic-ai. The span panel below shows the agent run: span_name agent run, level Info, service_name unknown_service, otel_scope_name pydantic-ai, kind span, and truncated trace and span IDs. Under an Agent Run tab, a system input reads 'Extract information about the city', a user input describes London's population and its landmarks, and the assistant output opens on a tool call.

Why observability

AI apps break quietly

Two failures can look identical to a user waiting on an answer. One agent stalls on a failed GitHub API request, another spends its whole runtime in a slow SELECT. The model call alone cannot explain either one.

Instrument the agent framework, HTTP client, and database driver, and Pydantic Logfire records the request, model, tool, external API, and database work as one trace. Degraded dependency is visible instead of inferred from timestamps across separate tools.

How it works

The trace is the shape of your code

  1. Instrument

    One line per library logfire.instrument_openai()

  2. Nest

    Each call opens a span inside the call that made it

  3. Follow

    One trace ID crosses services, queues and background tasks

  4. Extend

    Anything already speaking OpenTelemetry joins the same trace

What you get

Every run, end to end

  • The Logfire integrations page. A copyable logfire.instrument_fastapi(app) snippet sits above a grid of integration chips: FastAPI selected, then Django, Flask, Starlette, psycopg, SQLAlchemy, asyncpg, PyMongo, Redis, httpx, requests, aiohttp, Celery, Kubernetes, Docker, Airflow, Gunicorn, Stripe, structlog, Loguru, MySQL and Elasticsearch.

    Full-stack context

    37 integrations: web frameworks, eight databases, HTTP clients, task queues, hosts, Kubernetes and Docker.

  • A P95 latency chart for acme-api over 24 hours, climbing through a dashed 2 second threshold. A Slack notification reads 'Sent to #prod-alerts, p95 > 2s for 5 min', with the crossing point marked Alert.

    Dashboards and alerts

    Prebuilt dashboards for cost, latency, and exceptions. Alert from a template for exceptions, 5xx, slow queries, or LLM errors, or customize with your own SQL.

  • Model comparison dashboard showing two cards side by side: gpt-4o with 24.8k calls, 1.0% exceptions, 820ms avg latency, and $184 cost; and us.anthropic.claude-sonnet-4-2025 with 12.1k calls, 5.0% exceptions, 1.4s avg latency, and $96.7+ cost. Each card also shows speed, input/output tokens, cache reads, truncation rate, and tool call percentage

    Tokens and cost per model

    Query tokens and cost by model, provider, and agent alongside latency, error rate, output tokens/sec, cache reads, and tool-call rate.

  • Trace waterfall view showing nested API calls and spans for a chat billing agent. Rows include POST /v1/chat requests, an invoke_agent billing_agent span, chat gpt-4o calls, an execute_tool check_stock span with a SQL query, each annotated with cost and duration shown as horizontal bars.

    Live view with SQL search

    Search the live stream with a WHERE clause, or ask in plain English and let AI write the query. Standard PostgreSQL over the same table your traces live in, so nothing new to learn.

  • A Checkout availability service level over a 30 day rolling window. Current is 99.96% against a 99.9% target, with 35% of the error budget remaining and a note that the burn rate is 0.4x with no alerts firing.

    Service levels

    Set a target on availability, latency, LLM calls or AI quality. Logfire tracks the error budget and alerts on burn rate before you spend it.

  • Four span attributes. user_id reads usr_8231 and span_name reads fetch_order, while authorization and api_key both read [Scrubbed due to 'auth']. A toggle at the foot shows scrubbing on.

    Scrubbing on by default

    18 patterns redact passwords, tokens, keys and PII before data leaves the machine. On by default.

Start free Read docs

Use cases

Questions you can finally answer

  • Was it the tool or the model?

    When an agent gives a bad answer, the model usually gets blamed. The trace shows the tool call, what returned, and where the run went wrong.

    Debug a slow tool call

  • Where is the time going?

    Sort a slow run by duration, open the longest span, and follow it down to the exact SQL statement or API call behind it.

    Find the slow endpoint

  • Ask your coding agent what broke

    One command connects Claude Code or Cursor to the Logfire MCP server. It queries production itself and comes back with the trace.

    Set up the MCP server

Customer stories

Teams who stopped guessing

FAQs

How do I trace an AI agent end to end?

Install the Logfire SDK, call logfire.configure(), and instrument your framework — one line for Pydantic AI, LangChain, the OpenAI SDK, and 40+ others. From then on, every agent run is captured as a single trace: the model calls, tool calls, retrieval steps, and the database and API calls around them, nested in the order they ran. You watch it locally as you build and in production without changing the setup.

Does Logfire trace the whole request, or just the LLM call?

The whole request. Most LLM observability tools stop at the model call: prompt, response, tokens. Logfire traces the full application: the FastAPI request, the Postgres query, the vector search, the tool call, and the model call, in one waterfall. That matters because production failures usually aren't in the model call itself. They're in the retry logic, the query that fed the prompt, or the tool that timed out.

Do I still need Logfire if I already use Datadog or Sentry?

If you're shipping AI in production, yes. Logfire connects agent runs, model calls, tools, and application spans in one trace, with purpose-built AI views and SQL over the same data. Because it's OpenTelemetry-native, you can run it alongside Datadog or Sentry without changing your current instrumentation.

How does Logfire help with RAG pipelines?

RAG failures are rarely just the LLM's fault. They hide in retrieval: slow vector searches, mismatched embeddings, irrelevant context passed to the model. Because Logfire traces your full application, you can see retrieval latency, database queries, and LLM calls in the same trace, which makes it much easier to locate the real bottleneck.

How does Logfire handle sensitive data and PII?

Logfire automatically scrubs known sensitive fields such as passwords, tokens, keys, and common PII patterns, before data leaves your application. You can configure additional scrubbing rules for anything specific to your use case. For teams with stricter requirements, the enterprise self-hosted option keeps all data within your own infrastructure.

Does tracing add latency to my agents?

No. Spans are batched and exported asynchronously on a background thread, so instrumentation stays out of the request path. For high-volume services, head and tail sampling let you keep every failed or slow run while sampling the routine ones, so you control the data volume without losing the traces that matter.

Get started with Logfire for free

Sign up today and see your first trace in under 2 minutes

01 — Install 

$ uv add logfire

Resolved 7 packages in 128ms
Installed 7 packages in 89ms
+ logfire

02 — Instrument 

import logfire

logfire.configure()
logfire.info('Hello {name}', name='world')

Free up to 10m records per month No credit card needed