APM and distributed tracing without a proprietary agent. Auto-instrument your framework, database and HTTP clients in one line each, then query every span with SQL. Free for 10 million spans, logs and metrics a month.
// instrumentation.ts, loaded before your app:
// tsx --import ./instrumentation.ts server.ts
// Spans come from
// @opentelemetry/auto-instrumentations-node.
import * as logfire from '@pydantic/logfire-node'
logfire.configure({ serviceName: 'checkout' })import logfire
logfire.configure(service_name='checkout')
logfire.instrument_fastapi(app)
logfire.instrument_asyncpg()let logfire = logfire::configure()
.with_service_name("checkout")
.finish()?;
// Hold for the process lifetime; flushes on drop.
let _guard = logfire.shutdown_guard();# Java, .NET, Go, Ruby, PHP: no Logfire SDK needed. Point the
# standard OpenTelemetry exporter at us and the traces arrive.
export OTEL_EXPORTER_OTLP_ENDPOINT=https://logfire-us.pydantic.dev
export OTEL_EXPORTER_OTLP_HEADERS='Authorization=your-write-token'
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
Application performance monitoring is measuring how your application behaves in production: how long requests take, where that time goes, which
ones fail, and why. Modern APM does it with distributed tracing, recording each request as a trace made of spans, so a slow
checkout resolves to the exact SELECT inside it rather than to a service-level average.
The difference from logging is causality. A log line says something happened somewhere. A span says this request called this handler, which ran this query, which called this downstream service, and here is how long each step took. That chain is what turns "the API is slow" into a specific line of code.
import logfire
logfire.configure(service_name='checkout')
logfire.instrument_fastapi(app)
logfire.instrument_asyncpg()
logfire.instrument_httpx()
logfire.instrument_redis()"OpenTelemetry-native" too often means you write every span yourself. Logfire ships one-line instrumentation for the frameworks, drivers, HTTP clients, task queues and cloud SDKs applications actually use, so a typical service produces a full trace before you have written a single manual span. Add your own where the business logic deserves a name. The integrations guide has the full list.
A single bad query will drag an endpoint down and run up the database bill, and it is hard to spot among everything else the request does. Instrumenting your driver records each statement as its own span with its duration and its parameters, so the SELECT that added a second to checkout is a row in the waterfall rather than something you reproduce locally and guess at.
The signature of an N+1 is unmistakable in a trace: the same query span repeated dozens of times inside one parent. Because spans are queryable, you can go further and ask for every trace in the last hour with more than fifty database spans, which finds the endpoints you did not know had the problem instead of only confirming the one you suspected.
Trace context propagates across HTTP and message queues, so a failure three services deep still resolves to the request that started it. Exceptions are attached to the span that raised them with their stack trace, and identical exceptions group into issues, so a new failure mode is one entry rather than ten thousand log lines.
Every span carries its attributes, so p95 by endpoint, by customer, by region or by deploy is a GROUP BY rather than a metric you had to predict you would need. High-cardinality dimensions are ordinary columns here, which is the difference between answering a question and discovering nobody added that tag six months ago.
Spans carry service name, version and environment, so you can compare the hour before a deploy with the hour after on the same query and see which endpoint moved. Alerts run the same SQL on a schedule, so the check that found a regression once can watch for it permanently.
Logs are spans without a duration, and metrics sit in the same store, so correlating them does not mean exporting from one product into another. Open a slow trace and the log lines written during it are already there, in order, with the span that emitted them.
Observability has produced a remarkable number of query languages. PromQL. LogQL. TraceQL. NRQL. SPL. ES|QL. KQL. DQL. The fragmentation is enough of a problem that the CNCF has an initiative to standardize them. Logfire uses SQL, in PostgreSQL syntax.
select
attributes->>'db.statement' as query,
count(*) as calls,
sum(duration) as total_seconds
from records
where span_name = 'SELECT'
and start_timestamp > now() - interval '1 hour'
group by query
order by total_seconds desc
limit 10;
The category is arriving here too. As of August 2026 Braintrust recommends SQL and has demoted its own query language to legacy, NRQL was designed to read like SQL, and ES|QL is Elastic's move away from their older DSL. We started here, which means the useful queries
are the ones you would have written anyway, including the ones nobody thought to build a UI for:
select
trace_id,
count(*) as query_count,
min(start_timestamp) as started
from records
where attributes->>'db.statement' is not null
and start_timestamp > now() - interval '1 hour'
group by trace_id
having count(*) > 50
order by query_count desc;It is also the SQL a coding agent already knows. Point Claude Code, Cursor or Codex at the Logfire MCP server and ask which endpoint regressed after Tuesday's deploy: it writes the query, because the query is ordinary SQL rather than a dialect it has seen a handful of examples of.
Standard SQL is only worth having if the thing underneath it is quick. Ours is called FusionFire, and it is the part of Logfire we are most pleased with.
It is built on Apache DataFusion, a columnar, streaming, vectorized engine that uses Apache Arrow as its in-memory format, and shaped around what observability actually asks of a database, which is not what most databases are tuned for: scan an enormous number of spans, filter on attributes nobody indexed in advance, and come back before the person asking has lost their train of thought.
Every AI-native vendor has a name for theirs now. Braintrust has Brainstore, Langfuse runs on ClickHouse. The reason to say ours out loud is that it is the one you can point ordinary SQL at. A purpose-built store normally arrives with a bespoke API, because the store is the product and the API is how you are kept close to it. Fast and familiar are not in tension here.
We are not going to publish a benchmark you cannot re-run yourself. But it is genuinely interesting engineering and we like talking about it, so ask us about it.
Logfire bills records. Ten million spans, logs and metrics a month are free, then it is $2 per million. There is no per-host charge and no per-agent charge, so instrumenting another service on a machine you already send from does not change the shape of the bill.
That is the part worth checking against whoever you are comparing us with, because the incumbent model is usually the opposite. Datadog lists APM at $31 per host per month billed annually and Infrastructure Pro at $15 per host per month, with indexed spans metered separately on top (datadoghq.com/pricing, retrieved August 2026). Our Datadog comparison works that through properly.
One thing to know rather than discover: on Personal, hitting ten million pauses ingestion rather than billing you for the overage, so you cannot owe us anything on the free plan. Paid plans take a spending cap you set: past it new telemetry is hidden rather than dropped, and raising the cap brings it back.
If you already emit OpenTelemetry, moving to Logfire is a new endpoint and a token. If you are on a proprietary agent, you reinstrument once with OTel and are then permanently free of that decision, because the next migration after this one is a config change. We publish guides for Datadog, Grafana, Honeycomb, New Relic, Dynatrace, Splunk, Elastic and AWS ADOT.
The same property is what makes leaving us easy, which is the point. Instrumentation written against an open standard is an asset you own rather than something rented from whoever you signed with.
We are finding and fixing issues in five minutes instead of an hour, which is obviously increasing uptime for our clients.
APM is the practice of measuring how an application behaves in production: how long requests take, where the time goes, which ones fail and why. Modern APM does this with distributed tracing, recording each request as a trace made of spans so you can see the whole path across services rather than a per-service average. The point is to answer 'why was this request slow' rather than 'what is our p95'.
A log line records that something happened. A trace records a causal chain: this HTTP request called this handler, which ran this query, which called this downstream service. Each step is a span with a start time, a duration, a parent and its own attributes. Logs tell you what happened somewhere; a trace tells you what happened to one specific request, in order, across every service it touched.
No. Logfire ships one-line instrumentation for the frameworks, databases, HTTP clients, task queues and cloud SDKs most applications already use, so a typical service produces useful traces without any hand-written spans. You add manual spans where your own business logic needs naming, which is usually a handful of places rather than everywhere.
Logfire is an OpenTelemetry backend, not an OpenTelemetry wrapper. Point any OTLP exporter at it, from any language with an OTel SDK, using standard OTel instrumentation. There is no proprietary agent to install and no proprietary wire format, so the instrumentation you write is portable to another backend if you ever want to leave.
If you are already emitting OpenTelemetry, migration is repointing your OTLP exporter at Logfire's endpoint and setting a token. If you are on a proprietary agent, you replace it with OTel instrumentation once and are then free of that decision permanently. We publish migration guides for Datadog, Grafana, Honeycomb, New Relic, Dynatrace, Splunk, Elastic and AWS ADOT.
Span attributes are stored as structured data and queried directly, so a user ID, a tenant ID or a request ID is an ordinary column expression rather than a tag that blows up a metrics index. Grouping by a high-cardinality attribute is a GROUP BY, and it costs what a GROUP BY costs, which is the main structural advantage of querying traces instead of pre-aggregated metrics.
Many teams keep everything: Personal includes 10 million spans, logs and metrics a month and pauses ingestion at the limit. Team and Growth include the same allowance, then charge $2 per million additional records. When volume makes that impractical, Logfire supports both head and tail sampling, so you can keep every slow or failed request while sampling the routine ones.
Yes, and they are the same table. A log is a span with no duration, and metrics live beside them, so a query can join a slow trace to the log lines emitted inside it without exporting anything or switching products. This is the practical reason the single SQL interface matters more than it sounds like it should.
Get started with 10 million free spans, logs, and metrics per month. No credit card required.