One page, dozens of database calls
A list page that used to be quick now takes a second or two, and it gets worse as the list gets longer. Every individual query looks fine when you check it. Ten items are fine; a hundred are not.
Why it is hard to see
This is an N+1, and it is born inside a render: something fetches a list, then fetches a related record per item. Each query is genuinely fast, which is why per-request timing does not catch it and why it survives review — the code reads perfectly sensibly. Only the count is wrong.
It usually arrives with a refactor rather than with a feature. Moving a fetch into a component that renders once per row is a one-line change and turns one query into as many rows as you have.
What Sixty does about it
Database calls are counted per render and compared across releases, so the finding is "this operation made one query per render and now makes fourteen, since this deploy" rather than a latency number you have to interpret. The stack frames come with it, so the render responsible is named.
That evidence goes to your coding agent over MCP: the query, the frames, the before and after counts, and which child calls account for the change.
What it does not do
Counting calls per render needs a server agent, and there is one for Node, Python, Go, Ruby and PHP — but only Node gets it without being asked. Its build transform opens a span per exported async function on its own; everywhere else you mark the code worth measuring (a decorator in Python, two lines in Go, a module include in Ruby, one call in PHP) and the attribution is the same afterwards. Java, .NET, Rust and Elixir have no agent at all. The browser half works with any backend but sees only what the page itself asks for.
OpenTelemetry
Already have OpenTelemetry?
Keep your current collector and exporters. Sixty can ingest its connected traces and useful runtime metrics to infer release regressions; native agents provide deeper function and database-driver detail where available.