# Shared Host Ephemeral Port Exhaustion Caused Overnight Job Failures

DevFeed: [Shared Host Ephemeral Port Exhaustion Caused Overnight Job Failures](<https://devfeed.tech/articles/we-ran-out-of-tcp-ports-at-1-30-am-the-crack-was-tcp-tw-reuse-0-26518.md>)

Original publisher: [Read original article](<https://medium.com/engineering-housing/we-ran-out-of-tcp-ports-at-1-30-am-the-crack-was-tcp-tw-reuse-0-54952bf5f7bd?source=rss----3a69e32e2594---4>)

Author: PULKIT GARG

Published: 2026-08-11T05:58:23Z

Content type: article

Language: en

Sources: [Housing.com](<https://devfeed.tech/sources/housing-com.md>)

Topics: [ephemeral ports](<https://devfeed.tech/topics/ephemeral-ports.md>), [incident](<https://devfeed.tech/topics/incident.md>), [Kernel](<https://devfeed.tech/topics/kernel.md>)

Tags: [incident](<https://devfeed.tech/tags/incident.md>), [port](<https://devfeed.tech/tags/port.md>), [production-issue](<https://devfeed.tech/tags/production-issue.md>), [rate-limiting](<https://devfeed.tech/tags/rate-limiting.md>), [ruby-on-rails](<https://devfeed.tech/tags/ruby-on-rails.md>), [tcp](<https://devfeed.tech/tags/tcp.md>)

## AI overview

An engineering incident report explains how a neighboring bulk job exhausted the shared operating system's ephemeral TCP port pool, causing scheduled background jobs to fail until the temporary traffic pressure subsided.

## Source excerpt

A neighbor's bulk job drained every ephemeral port on a shared box. Twice. Here's the one kernel setting that would have stopped it -- and the architecture that makes it a non-issue. At 1:38 AM, one of our background-job services started failing. Scheduled jobs -- the nudges and reminders we send users overnight -- began throwing an error most engineers rarely see: Errno::EADDRNOTAVAIL -- Cannot assign requested address Not "connection refused." Not "timeout." Cannot assign requested address. The machine wasn't saying the other end was down. It was saying it had run out of addresses to call from. Here's the strange part: we hadn't deployed anything. Our code was untouched for days. And by ~3 AM it healed itself, with nobody doing a thing. Two nights later, same window, it happened again. The bug wasn't in our service. It was in a service we don't own -- and don't even talk to. Act 1: A crime scene with no suspect ~7,800 job executions failed across the two nights. The first night slipped in under the alerting threshold entirely -- we only found it in the errors inbox after the fact. Everything about it was confusing: Our service hadn't changed. The internal APIs we call were all healthy. It happened in a tight window (~1:30-3:00 AM), then vanished. No human fixed it. It just... stopped. An outage that fixes itself is telling you something important: the thing that broke wasn't yours, and the pressure that caused it was temporary. Act 2: The noisy neighbor That service doesn't run on its own machine. It shares one box with about ten other apps -- a normal, cost-efficient setup. What's easy to forget is what they silently share: not just CPU and memory, but the operating system's ephemeral port pool. Quick refresher. Every time a program opens an outbound TCP connection, the OS assigns it a temporary "ephemeral" source port. That pool is finite -- by default, roughly 28,000 ports. And on a shared box, every app draws from the same pool. Ephemeral ports are an unmonitored, multi