New: Cookbooks and AI ExplanationsStep-by-Step recipes to solve problems connected to Roadmaps and Cheat Sheets. Need more details? Use AI buttons for structured and simple explanations with concrete examples throughout the whole platform.Take a look
An endpoint is slow and I genuinely can't tell if it's my code, a slow query, or the network in between.
What you'll have at the end
One trace per request showing exactly which span, your code or the database, ate the time
You need
A web service already answering real requests, backed by a real database for at least one of its endpoints, that also makes at least one outbound call to another service while handling a request.
Not covered
Fixing whatever the trace ends up blaming, whether that's rewriting a query, adding an index, or optimizing your own code: the right fix depends entirely on what you find, and belongs to whatever problem you're now debugging.
Leans on
Find and fix the N+1 queries hiding in a nested API response
Once the rank shows many small, same-shaped child spans instead of one big one, that's a different pattern with its own fix, and that's where it lives.
Give every request a correlation ID that survives your stack
If the real question is only whose log lines belong to whom, not which hop cost the time, a shared id is the lighter answer.
Your dashboard is missing the four golden signals
Once you've diagnosed this one request, folding its endpoint's average and percentile latency onto a dashboard is what catches the next one before a person has to go looking.
Checked 19 Aug 2026
Part of the Backend Observability and Monitoring cookbook