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
The server-side half of this needs Node and Postgres today — the build plugin and the query attribution are what count calls per render. Python, Ruby, Go and the rest are not supported, and the browser half works with any backend but sees only what the page itself asks for.