The application is slow.
The developer says the server is slow. The hosting provider says the server is fine. The network provider says there is no packet loss.
Everyone has now supplied an answer and nobody has solved the problem.
"Slow" is not a layer
A user experiences the whole system. Their request may pass through DNS, a network, a reverse proxy, an application server, a cache, a database and storage before anything appears on screen. Any one of those can add the latency.
Looking only at the component your company owns is therefore an excellent way to prove that your component is innocent, while leaving the customer with precisely the problem they started with.
Start with a request and follow it
Useful diagnosis starts with measurement. How long does DNS take? How long to establish the connection? When does the first byte arrive? How long does the application spend processing? Which queries run, and how long do they take? Is storage waiting? Is CPU saturated? Is memory pressure causing swapping? Does this affect every request, or one operation?
The goal is to turn "slow" into a timeline. Once you know where the time is going, the organisational argument stops being interesting.
Infrastructure metrics need application context
A server at 20% CPU can host a slow application. A server at 90% CPU can host a perfectly responsive one.
Infrastructure graphs are evidence, not verdicts, and they have to be read alongside application behaviour. Equally, a trace showing a slow database call does not mean the database server needs more CPU. The query may simply be terrible.
Ownership boundaries become diagnostic boundaries
When the application and the infrastructure belong to different suppliers, each team has excellent visibility into its own layer and very little into the other. That is manageable when both teams collaborate.
It becomes painful when the contract boundary turns into the troubleshooting boundary, and the customer is left holding both halves of an unanswered question.
One reason we like operating both is mundane: we can keep following the request. We do not have to stop at the edge of the virtual machine and open a ticket with ourselves.
The answer can still be somebody else
Owning more layers does not make every problem ours. A third-party API can be slow. An office connection can be broken. An upstream carrier can have a bad afternoon.
The advantage is not having somebody convenient to blame. It is being able to collect enough evidence to say where the problem actually is.