Error guide

Connection reset by peer (ECONNRESET)

An established connection was abruptly terminated by the other end, mid-exchange.

Connection reset by peer means a connection that had been established was terminated abruptly — the other end sent a TCP reset instead of closing cleanly. The exchange was underway and stopped in the middle, so it is a different failure from a connection that was never made.

The most common benign cause is a keep-alive race. The server closes an idle connection at the same moment the client reuses it, and the client sees a reset for a request the server never processed. This is normal at any scale, it is why HTTP clients retry idempotent requests, and a low background rate of it means nothing.

The causes that matter kill connections that were doing work: a process crashing or being killed mid-response, a load balancer dropping connections during a deployment, a resource limit being hit, or a middlebox — a firewall, a proxy, sometimes an ISP device — deciding to terminate the connection for reasons of its own.

Common causes

  • An idle keep-alive connection closed by the server as the client reuses it — usually harmless.
  • The server process crashing or being killed while responding.
  • A load balancer or proxy dropping connections during a deploy or a scaling event.
  • A connection or request limit terminating the connection abruptly.
  • A firewall or middlebox resetting connections it classifies as unwanted.
  • A request body larger than the server accepts, cut off rather than answered.

How to diagnose it

  1. Establish whether resets happen on idle connections or mid-request; the first is usually benign and the second is not.
  2. Check for process crashes, out-of-memory kills and restarts around the times of the resets.
  3. Compare the keep-alive timeouts on each hop — a client holding connections longer than the server keeps them produces exactly this race.
  4. Check whether resets cluster around deploys or scaling events.
  5. Look for size or rate limits if the resets correlate with particular requests rather than particular times.

Whose fault is it? It depends which layer

The reset comes from the peer, so usually the server side or something between. A steady low rate from keep-alive races is not a fault at all, which is why the rate and the timing matter more than the presence of the error.

What monitoring sees

A reset is an established-connection failure — the peer was reached and then cut the exchange — so it is treated as a real signal about the target rather than as possible trouble on the monitor's own path. Because resets are frequently transient, the failure threshold does the useful work here: a single reset check is recorded as downtime without paging, and consecutive ones declare an incident.

Related error guides

Terms used on this page

Questions

Are occasional ECONNRESET errors a problem?

A low steady rate usually is not — it is the normal race between a server closing an idle keep-alive connection and a client reusing it. Resets that interrupt requests in progress are a different matter and worth investigating.

How is a reset different from a timeout?

A reset is an active termination of a connection that existed: something decided to end it. A timeout is silence — nothing answered at all. Reset is fast and definite; a timeout is slow and ambiguous.

One of the Uptimely HTTP and network error guides, written for the person who operates the server rather than the one refreshing the page. Something here read wrong to you? Email support@getuptimely.com.