Three seconds, roughly, and every month it took a little longer.
It returned an account balance in a lending system. No slow join, no missing index: it summed the account's entire entry history on every call. At launch that was a few hundred rows. A year in it was far more. The query plan never changed. The input did.
What made it visible was the caller. A moderation screen listed accounts and asked for each balance in its own request, so one page load fired dozens of full-history sums at once. Alone the endpoint looked tolerable. Under its real access pattern it was the slowest thing in the product.
So I stopped treating it as a query problem. Balances now come from a stored total per closed period: the period keeps its computed value, and a read sums only the entries recorded after it. The scan is bounded by recent activity, not by the lifetime of the account. That moved the response into the low hundreds of milliseconds and, more importantly, kept it there.
The lesson I carry is that response time is a slope and not a number. Anything priced in rows since inception is a scheduled outage with no date on it yet.
When you look at latency, I'd ask whether you check how it moved over the last six months, or only today's p95...