Guide: reading a trace
Every request has a trace. Here is how to find it, what each span means, and how to tell our latency from yours...
Every response from Digest carries an X-Trace-Id header. Paste it into the dashboard, or into digest trace <id>, and you get the request's timeline. This guide is how to read it.
The spans
- edge: from the request reaching our network to reaching an API node. Usually under 5ms. Larger means a slow path from you to us.
- auth: key lookup and rate-limit check. Cached; under 1ms.
- query: the database. This is where time goes. The span carries the query plan.
- serialize: building the response. Scales with rows.
- transfer: sending it to you. Scales with bytes and your bandwidth.
Whose latency is it
Add edge and transfer: that is the network. Add the rest: that is us. If the total on your side is much larger than the trace total, the time is in your client, before the request left or after the response arrived.
A slow query span
Open the plan. A sequential scan on a large table means a filter with no index; the plan names the column. Filters on indexed columns are listed in the docs, and the query page in the dashboard warns before you run one that is not.
Retention
Traces are kept for fourteen days. Include the id in any support request and the answer comes faster.
Release notes by email
Every release and every incident report, the day it is published. Nothing else.
Digest Engineering
The team that builds Digest. Release notes are signed by the team; incident reports by whoever was on call.
All Posts