Error: read ECONNRESET

What it means

ECONNRESET means a TCP connection that was already established was torn down by the other end with an RST packet rather than closed politely. Your side finds out by trying to use it: the read or write fails, and the error names the syscall rather than anything about why the peer went away.

What makes this a characteristically serverless problem is the execution environment lifecycle. Lambda freezes a container after an invocation and thaws it for the next, which is what makes warm starts fast. But freezing does not close sockets — it suspends the process holding them. A connection pool created at module scope, deliberately, to be reused across invocations, sits there with open sockets while nothing is running. If the peer's idle timeout is sixty seconds and the function is invoked every ninety, that pool is holding a dead connection every single time it wakes up, and the first query of each warm invocation discovers it.

That produces a failure pattern that reads as random and is not. Cold starts always work, because they open fresh connections. Busy periods work, because the sockets never idle long enough. The failures cluster on the first request after a lull, at a rate that tracks how sparse your traffic is — which is exactly the shape that survives every load test and appears in production during the quiet hours.

The fix follows directly from the mechanism, and it is worth being clear about which one you need. Retrying works because a reset from a stale socket succeeds immediately on a new one. Setting your pool's idle timeout below the peer's works better, because it removes the race rather than recovering from it. And for relational databases the underlying tension — every execution environment holding its own connections, none of them shareable — is what RDS Proxy exists to solve. Distinguishing a stale-socket reset from a peer that is genuinely failing comes down to whether the resets fall on first-calls-after-idle or arrive all at once across every concurrent execution, which is a question about the invocation's position in its container's life rather than about the error text.

What it looks like in CloudWatch

This is the shape the failure arrives in: the lines of one invocation scattered among everything else the log group received at the same moment.

The panel on the right is generated by running the excerpt on the left through the same parser that powers the free web stitcher — it is what the tool actually produces for this input, not an illustration of it.

How to confirm it from the logs

The important question is whether the reset happens on the first call of an invocation or a later one. A reset on the first outbound call of a warm container is the classic stale-keepalive case — the connection was cached from a previous invocation and the peer dropped it during the gap. A reset mid-invocation, after other calls have succeeded, points at the peer actively closing rather than at staleness.

Check the timing too. Resets that cluster after a period of low traffic, or that always fall on the first request after a quiet spell, are almost always idle-timeout related. Resets spread evenly across a busy period usually mean the peer is shedding load or restarting.

Causes, most likely first

Fixes

jsasync function withRetry(operation, attempts = 3) {
  for (let attempt = 1; attempt <= attempts; attempt += 1) {
    try {
      return await operation();
    } catch (error) {
      const transient = ["ECONNRESET", "EPIPE", "ETIMEDOUT"].includes(error.code);
      if (!transient || attempt === attempts) throw error;
      await new Promise((r) => setTimeout(r, 2 ** attempt * 50));
    }
  }
}

jsimport pg from "pg";

// Module scope: reused across invocations on this container.
const pool = new pg.Pool({
  max: 1,                       // one socket per execution environment
  idleTimeoutMillis: 30_000,    // below a typical 60s peer idle timeout
  connectionTimeoutMillis: 3_000
});

yamlResources:
  DbProxy:
    Type: AWS::RDS::DBProxy
    Properties:
      EngineFamily: POSTGRESQL
      IdleClientTimeout: 1800
      RequireTLS: true

Also seen as

The same underlying failure, worded differently by a different runtime, SDK version, or logging layer. All of these land here — there is no separate page for each phrasing.

Related errors

Errors that show up alongside this one, or that people mistake for it.

References

• AWS Lambda Developer Guide — Lambda execution environment lifecycle
• AWS Lambda Developer Guide — Using Amazon RDS Proxy with Lambda