I used to think timeouts were simple: set a timeout, request fails after X seconds, done. Then I shipped a Node.js service that still got stuck under load even though “everything had a timeout.”
Turns out Node has multiple layers of timeouts, and if you set the wrong one (or only one), you can still end up with requests that hang, sockets that live forever, and a server that slowly stops accepting traffic.
Here’s the story — and how I fixed it.
<hr>
<h2>The Symptom: “Random” Hangs Under Load</h2>
It started as a vague report:
<ul>
<li>“The API sometimes takes forever.”</li>
<li>“It’s not crashing, it just… stops responding.”</li>
</ul>
CPU was fine. Memory was fine. No obvious errors.
But the number of open connections kept climbing. And once it crossed a certain point, even healthy endpoints felt slow.
Classic “works until it doesn’t.”
<hr>
<h2>The Mistake: I Only Set the Wrong Timeout</h2>
I had code like this:
JavaScript (Node.js):
<pre><code>import http from &quot;http&quot;;

const server = http.createServer(async (req, res) =&gt; {
 // ...business logic
 res.end(&quot;ok&quot;);
});

// I thought this solved it:
server.setTimeout(10_000);

server.listen(3000);
</code></pre>
I believed <code>server.setTimeout()</code> meant:
<blockquote>
“Kill any request that takes longer than 10 seconds.”
</blockquote>
Nope.
That timeout is mainly about idle socket activity (and behavior differs across Node versions and request patterns). If the connection is still “active” in certain ways, you can still end up with long-lived sockets.
And even worse: my outbound calls (to other services) didn’t have proper timeouts either.
<hr>
<h2>The Real Root Cause: Outbound Requests Without Timeouts</h2>
We had a dependency call like:
<pre><code>const r = await fetch(&quot;https://some-service/api/data&quot;);
// sometimes this never returned under network weirdness
</code></pre>
In the real world:
<ul>
<li>DNS can hang</li>
<li>TLS negotiation can stall</li>
<li>upstream can accept the connection but never respond</li>
<li>proxies can behave badly</li>
</ul>
If you don’t set timeouts on outbound calls, your handler can hang while the client connection stays open… and then your server slowly fills up with stuck requests.
<hr>
<h2>The Fix: Put Timeouts at the Right Layers</h2>
I fixed it with a three-layer timeout strategy:
<h3>1) Request-level timeout (application logic)</h3>
Use <code>AbortController</code> so the operation stops.
JavaScript (Node.js 18+):
<pre><code>async function fetchWithTimeout(url, ms = 5000) {
 const controller = new AbortController();
 const id = setTimeout(() =&gt; controller.abort(), ms);

 try {
 const res = await fetch(url, { signal: controller.signal });
 return res;
 } finally {
 clearTimeout(id);
 }
}
</code></pre>
Now my outbound call can’t hang forever.
<hr>
<h3>2) Server headers timeout (protect against slowloris / slow clients)</h3>
These are more reliable for “client is too slow” cases.
<pre><code>server.headersTimeout = 12_000; // must be &gt; requestTimeout in Node
server.requestTimeout = 10_000;
</code></pre>
This helps when clients keep connections open and drip headers/body slowly.
<hr>
<h3>3) Hard kill per request (safety net)</h3>
Even if something slips through, I wanted a final cutoff.
<pre><code>server.on(&quot;request&quot;, (req, res) =&gt; {
 req.setTimeout(10_000, () =&gt; {
 res.statusCode = 408;
 res.end(&quot;Request timeout&quot;);
 req.destroy();
 });
});
</code></pre>
This makes the behavior explicit and visible.
<hr>
<h2>Bonus: The One Change That Made Debugging Obvious</h2>
I added logging on aborted requests and tracked active handles:
<pre><code>process.on(&quot;warning&quot;, (w) =&gt; console.warn(w.name, w.message));

setInterval(() =&gt; {
 console.log(&quot;Active handles:&quot;, process._getActiveHandles().length);
}, 10_000);
</code></pre>
(Yes, <code>_getActiveHandles()</code> is not “clean,” but for debugging it quickly tells you if your server is accumulating stuck sockets/timers.)
Once I saw handles steadily increasing, it confirmed the leak was connections waiting on something — not memory.
<hr>
<h2>What I Learned</h2>
Node timeouts aren’t one thing. They’re:
<ul>
<li>Socket / HTTP server protection</li>
<li>Application request timeboxing</li>
<li>Outbound client timeout enforcement</li>
</ul>
If you only set one, you’ll still get weird hangs in production.
<hr>
<h2>Conclusion / Key takeaway</h2>
If your Node service “hangs” under load, assume it’s not mysterious. It’s usually requests waiting forever because timeouts weren’t enforced at the right layer.
Have you ever shipped a service that didn’t crash — it just slowly stopped responding? What did it end up being?

JS Development focuses on building modern, dynamic web applications using frameworks like React, Angular, and Vue.

JS Development

Node.js has multiple timeout layers that must be configured correctly to prevent hanging requests. Setting only `server.setTimeout()` is insufficient because it primarily handles idle socket activity, not stuck outbound requests. A proper solution requires three layers: request-level timeouts using `AbortController` for outbound calls, server-level `headersTimeout` and `requestTimeout` for slow clients, and per-request hard timeouts as a safety net. Without proper timeout enforcement at each layer, services can accumulate open connections and gradually stop responding under load, even without crashes or obvious errors.

The Day I Learned Node.js “Timeouts” Don’t Mean What I Thought They Meant

Good explanation. I really learned something new from by reading this post.

As a nodejs developer, I think this is really good info and might help with some API resource issue I also sometimes encounter. Never thought an unreturned fetch would actually not terminate itself.

good reading, seems to be what we need to implement on my team