Follow one slow customer request, separate waiting from application work, and choose the next investigation before changing infrastructure.
João Dezembro · 3 min
More in EngineeringTo diagnose a slow Node.js API, follow one slow customer request and measure where it spends time. Compare the customer's wait with server timing, then inspect database calls, external services and application work. Use those observations to choose the next check. Adding servers or changing code before locating the delay leaves you guessing.
A customer opens a report and waits. The same screen looks fine on a developer's laptop. Before discussing a larger server, ask which report was slow, when it happened, and whether the delay affected other customers too.
Work with an engineer who can follow that request through the deployed system. Keep the release, environment, data size and concurrent activity with the observation. A quick local run with a small dataset cannot explain what happened to that customer.
Fill this record with your engineer. Keep missing measurements visible.
| Record | What to capture |
|---|---|
| Customer and server timing | Keep the affected action and request identifier. Compare the customer's elapsed time with the measured server interval. If they differ, identify the unmeasured part before blaming application code. |
| Work inside the request | Use correlated trace spans or timing marks for database calls, external calls and application work. Check which operations overlap. Adding a parent span to its children counts some time twice. |
| Next investigation | A long external-call interval points to that dependency. A long database-call interval needs finer inspection before calling the query slow. If Node.js execution is implicated, use a CPU profile to inspect the work; event-loop delay alone does not identify its cause. |
| Decision and verification | Write the measured interval, competing explanation, next check and owner. After a change, compare the same action under comparable data and concurrent activity. Check that the result is still correct and errors have not increased. |
Imagine a report request whose trace spends most of its server interval waiting for a supplier API. The database call is short, and the report is assembled after the supplier replies. That observation gives the engineer a narrower question: what happens between sending that call and receiving its answer?
Inspect that call and compare another request under similar conditions. If the supplier interval is short but the request still takes a long time, the original explanation needs more work. If tracing stops at the outbound call, record that gap. The trace has directed an investigation; it has not established that a backend rewrite would help.
A trace only shows the work that was captured. Browser work, a proxy, network time or an uninstrumented operation can leave part of the customer's wait unexplained. Several causes can also appear during the same request. Keep the measurement boundary with the finding.
Ask the engineer to choose a safe collection method for the deployed runtime and workload. Limit overhead and avoid collecting customer content or credentials. For an active outage, contain the customer impact while preserving evidence rather than delaying recovery for a perfect trace.
Take the request record and its unknowns to the person responsible for the API. Gridfused can help investigate the affected workflow and plan or implement a targeted change.
Founder & Managing Director
Founder of Gridfused Technologies. Software architect and engineering leader focused on building reliable products, systems, and AI-enabled operations.
October 27, 2026
3 min
Categories
