See whether a release lines up with a change in request volume, errors, or latency, then open the exact request and span behind it. Built on OpenTelemetry, with no proprietary agent and ordinary SQL underneath.
The service-level rate, error, and latency charts are aggregations of the same OpenTelemetry spans you can inspect. When p95 moves after a version marker, open the affected operation and follow one slow request across handlers, queries, and downstream calls.
That keeps the investigation causal: a checkout 502 can resolve through payments-service to the 1.33-second Stripe request
that returned 504, without switching tools or correlating timestamps by hand.
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.
"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.
// 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()
logfire.instrument_httpx()
logfire.instrument_redis()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.
otlp=https://logfire-us.pydantic.dev
export OTEL_EXPORTER_OTLP_ENDPOINT=$otlp
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=$LOGFIRE_TOKEN"
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobufStart free with 10 million spans, logs, and metrics each month. No credit card required.
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.
Query spans, logs, and metrics with PostgreSQL-compatible SQL. Start from a saved query or write one directly, then keep the useful results as dashboards and alerts.
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;Because the query surface is SQL, you can group by attributes nobody indexed in advance, join telemetry, and investigate questions the UI did not anticipate:
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.
FusionFire is Logfire's purpose-built store for observability data. It keeps PostgreSQL-compatible SQL responsive across wide spans and high-cardinality attributes.
It is built on Apache DataFusion, a columnar, streaming, vectorized engine that uses Apache Arrow as its in-memory format. It is shaped around observability queries: scanning wide span collections and filtering on attributes that were not indexed in advance.
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 host-priced APM charges you for machines instead. Not all of them do: New Relic and Honeycomb both meter volume rather than hosts. 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 (Datadog pricing page, 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, which we set for you on request: past it new telemetry is hidden rather than dropped, and raising the cap brings it back.
If you already emit OpenTelemetry, Logfire is an OpenTelemetry backend: moving here is a new endpoint and a token. If you are on a proprietary agent, you replace that instrumentation once with OTel and are then permanently free of that decision, because the next migration after this one can be as small as 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.