Rate, errors and duration for every service, derived automatically from your traces, with per-service dependency topology built from trace context that actually propagated. A service exists because it sent a span.
import logfire
# A service exists because it sent a span.
logfire.configure(service_name='checkout',
service_version='2026.8.3')Most products in this space start with a registry: you write service definitions, declare ownership, and then spend the next two years keeping that description in sync with what is actually deployed. The inventory is only as true as the last person who remembered to update it.
Here a service exists because it sent a span. Set service_name when you configure the SDK and it appears; stop deploying
it and it goes quiet. The list cannot drift from reality, because the list is reality.
The trade is worth stating: this is the operational view of what your services are doing, not the organisational record of who owns them. There is no ownership, no teams, no tiers, no on-call routing and no runbook links. If you want golden paths and ownership metadata, that is a catalog product and this is not one.
Requests and throughput, error rate, and p95 and p99 duration for every service, derived from the traces you are already sending. Rate, errors and duration are the smallest set of numbers that tells you whether a service is healthy, so they are the default view rather than a dashboard you have to build first.
An edge exists because a parent span in one service has a child span in another. That means the graph describes calls that really happened in the window you are looking at, not a diagram someone drew in 2024. Each edge carries its call count, its errors and its p95, with width scaled by volume and color by error rate.
Set a service version and releases are marked on the charts, so a step change in latency or error rate lines up against the deploy that caused it. It is the cheapest observability win available and it costs one argument at configure time.
An edge that looks wrong is a question, and the answer is the traces behind it. Go from a service, to the dependency that is failing, to the individual requests that failed, without leaving for another product or reconstructing the path by hand.
Attach service level objectives to a service and its reliability view carries the error budget alongside the RED metrics, so 'is this healthy' and 'are we still within what we promised' are answered in the same place. See the SLOs page for how the burn-rate alerting works.
The service views are a convenient default over the same spans as everything else. When the built-in breakdown is not the one you need, the same numbers are a SQL query away, grouped by whatever attribute your question actually turns on.
Open a service and you see what calls it and what it calls, every edge carrying the call count, the errors and the p95 for the window you are looking at. An edge exists because a parent span in one service has a child span in another: the picture is the traffic, not a diagram somebody drew once and left to rot.
The scope is one hop in each direction, service to service, the shape you actually want during an incident, when you are already looking at one service and asking what it depends on. Databases and external calls stay in the trace, where their spans already are. A service busy enough to exceed 200 edges in the window shows its busiest 200.
The service views are a convenient default over the same data as everything else, so when the built-in breakdown is not the one your question needs, you write the question:
select
service_name as service,
count(*) as requests,
sum(case when is_exception then 1 else 0 end)
/ count(*)::double as error_rate,
approx_percentile_cont(duration, 0.95) as p95
from records
where start_timestamp > now() - interval '1 hour'
group by service
order by error_rate desc;Group by deployment, by customer tier or by region instead, and it is the same query. That is the difference between a view somebody built for you and a view you can build.
Related: APM and distributed tracing for the requests underneath these numbers, SLOs for holding a service to a target, and infrastructure monitoring for what it runs on.
It has per-service topology rather than a single project-wide map. Open a service and you see the services it calls and the services that call it, one hop out, built from real propagated trace context. There is no page that renders your whole system as one graph, so if a full auto-discovered system diagram is what you are shopping for, this is not that. In practice the one-hop view is what you actually use during an incident, because you are always looking at a specific service.
A service exists because it sent a span with a service name. There is nothing to register, no YAML definitions to write and no registry to keep in sync with reality, which means the list cannot drift from what is actually running. Set service_name when you configure the SDK and the service appears.
No, and it is worth being clear about the difference. There is no ownership, no teams, no service tiers, no on-call routing and no runbook links. This is the operational view of what your services are doing, not the organisational record of who owns them. If you need golden paths and ownership metadata, that is a different kind of product.
Rate, errors and duration: how many requests a service is handling, what fraction of them fail, and how long they take. They are the smallest set of numbers that tells you whether a service is healthy, which is why they are the default view rather than something you have to assemble. Logfire shows requests and throughput, error rate, and p95 and p99 duration per service.
From trace context that actually propagated. An edge exists because a parent span in one service has a child span in another, so the graph reflects calls that really happened in the window you are looking at rather than a configuration file someone wrote once. Each edge carries its call count, its errors and its p95.
It is service to service only, so databases and external APIs are not drawn as nodes even though their spans are in the trace. It shows one hop from the service you are looking at rather than the transitive graph. Only the focal service is health-colored. And it is capped at 200 edges, so an unusually busy service can be showing you a subset.
Yes. Set service_version when you configure the SDK and the trend charts mark releases, so a step change in error rate or latency lines up against the deploy that caused it. This is the cheapest observability win available and it takes one argument.
Get started with 10 million free spans, logs, and metrics per month. No credit card required.