16 / Follow the critical path
Read an API trace as a sequence of decisions, not a wall of spans
Inspect timing, parent-child relationships, retries, and failure hotspots in OpenTelemetry, Jaeger, or Zipkin trace data.
gatewayauthordersdatabasecritical pathorders.select_inventory
Working reference
What goes in, what comes out, and what the result can prove.
Concrete artifact
Distinguish total duration from the critical path
POST /checkout 842 ms
├─ inventory.reserve 118 ms
├─ payment.authorize 604 ms ERROR
│ └─ bank.request 571 ms timeout
└─ order.persist 41 msReview sequence
Three checks before the result becomes a decision.
Structure
Rebuild parent/child relationships and flag missing parents.
Critical path
Identify spans that actually determine end-to-end latency.
Context
Correlate errors with service, operation and attributes.
Limits
What this workflow does not prove.
- Sampling can omit the request or span that explains an incident.
- Clock skew can distort cross-service timing.
- Trace attributes may contain sensitive identifiers.
Questions worth answering
Before you put it into a real workflow.
Which formats are supported?
Common OpenTelemetry, Jaeger, and Zipkin JSON representations are supported.
Does this collect live production traces?
The public viewer focuses on trace artifacts you provide; production collection belongs in your observability pipeline.
Can I share a trace?
Use sharing only after reviewing and redacting attributes that may contain identifiers or secrets.
Next move
Start with one concrete API problem.
Keep the first step small. Move into a workspace when the result deserves to be saved, repeated, or shared.