See what the API is doing.

Track latency, errors, and throughput for the operations your services report. When something slows down, open the related traces and inspect which calls took the time.

healthywarningerror
operation · checkoutWarning

operation

mutation checkout

p99

318ms▲ 7.6×

latency / 5m

p95

42ms

throughput

1.2k/m

errors

0.3%

distributed trace · checkout7f3a·9b2e·c1 · 318ms
0ms100ms200ms318.0 ms
🌐POST /graphql318.0 ms
mutation checkout306.0 ms
users-svc · GET /me44.0 ms
billing · Charge204.0 ms
worker · receipt.enqueue58.0 ms
orders.db · INSERT38.0 ms
204ms of this 318ms request were spent in the billing service.

OpenTelemetry-native, end to end.

Configured services export supported traces, metrics, and logs over plain OTLP. Nitro links reported operation signals to the related distributed traces for investigation.

GraphQLRESTgRPCjobDB
  • Vendor-neutral OTLP in, no proprietary agent
  • Hot Chocolate is auto-instrumented
  • Works with any OpenTelemetry backend, not just Nitro
C#Program.cs
builder.Services
    .AddNitro()
    .AddOpenTelemetry();

builder.Services
    .AddGraphQLServer()
    .AddInstrumentation();

What’s slow. How bad. And for whom.

Rank operations to investigate with the impact score.

The impact score combines traffic, latency, and error rate to help you decide which reported operations to investigate first.

Operations

ranked by impact · last 1h

OperationAvg latencyThroughputErrorsLatencyImpact
Qmutation checkout
62 ms1.2k/m0.3%
QgRPC · Billing.Charge
204 ms610/m0.4%
QREST · POST /orders
31 ms1.4k/m0.0%
Qmutation applyCoupon
16 ms340/m1.4%
Qjob · receipt.worker
58 ms240/m0.2%

The whole latency picture, not an average.

An average can look healthy while a small number of requests are much slower. Percentiles show you where the tail starts, so you can find and fix those slow paths before they affect more users.

Latency · checkout

p95 / p99 · ms

p95p99
p99
318ms
p95
42ms
throughput
1.2k/m
error rate
0.31%

Know which identified clients are affected.

See which client apps and versions are behind an operation. When one starts causing trouble, you can tell whether it affects everyone or only a particular client.

Clients · checkout

share of impact

web-storefront
mobile-ios
android

Move from a metric spike to the related traces.

Follow one request through its reported trace.

Open the trace waterfall to inspect the services and spans that reported timing for one request, including which calls contributed the most latency.

Inspect the trace behind a failed operation.

When errors spike, open the failing operation and inspect its traces, spans, and captured exception details without correlating logs by hand.

The whole story, from spike to span.

Follow an incident from the latency chart to the affected operation and down to the spans behind it, without leaving Nitro.