Always-On repl idle timeout behavior for idle TCP connections

Question

Always‑On repls on Replit enter a sleep state after a period of no network activity, pausing CPU execution while preserving the filesystem. The platform does not expose the exact idle threshold, and its documentation does not clarify whether the timeout is triggered only when there is no data transfer on existing TCP connections or also when those connections remain open but idle. This ambiguity affects long‑running services that rely on persistent sockets (e.g., WebSocket servers, database clients) and need to know if the container will sleep while connections stay open.
Goal: Determine whether the idle‑sleep mechanism considers idle open sockets as activity, or if it treats them as no‑network‑activity, so developers can decide whether additional keep‑alive traffic is required to prevent unwanted suspension.
Uncertainty: Without a configurable timeout or explicit platform signal, it is unclear if maintaining an open TCP socket alone prevents the container from entering sleep, or if periodic payload exchange is necessary.
Specific questions:

Does Replit’s idle timeout count only active data packets, or does it also reset on idle open TCP connections?
Are there any platform‑provided settings or flags to adjust or disable the idle‑sleep behavior for socket‑based Always‑On repls?
What observable indicators (e.g., log messages, metrics) signal that the container has entered sleep due to lack of data versus lack of new connections?

Tasadduq Burney · Answer

Answer to the exact question
Replit’s Always‑On repls enter a sleep state when there is no observable network traffic for a period of time. An idle open TCP socket that does not send or receive packets is treated as inactivity and can trigger the sleep. Keeping the socket open alone does not guarantee that the container stays awake.
Confirmed facts

The platform does not expose a configurable timeout or flag to alter the idle‑sleep threshold.
Logs from the repl console often contain a line such as Repl sleeping or a sudden restart of the process after inactivity.
When a metrics dashboard is available, CPU usage drops and network activity flatlines during the sleep period.

Likely explanation
Replit monitors network‑activity metrics (packets sent/received) rather than the mere existence of open sockets. Therefore a socket that remains open but idle is considered the same as no network activity. To keep the repl awake you typically need to send periodic keep‑alive packets (e.g., a small ping or heartbeat) over the socket.
Steps to verify on your repl

Open a TCP connection to an external endpoint from inside the repl.
Leave the connection idle (no data sent or received) for at least 30 minutes.
Observe whether the repl remains responsive or if you see a Repl sleeping message in the console.
If you suspect the repl slept, send a keep‑alive byte once per minute and repeat the test to see if the sleep is avoided.

Observable indicators of sleep

Console log entry: Repl sleeping or Repl waking.
CPU usage spike followed by a pause in the metrics dashboard.
Connection attempts from external clients that result in a connection reset or a new process start.

Missing diagnostic detail
Does your repl run on a free or paid plan? Different plans may have slightly different thresholds. If you can share that, the recommendation can be fine‑tuned.

Always-On repl idle timeout behavior for idle TCP connections

1 answer

Answer to the exact question

Confirmed facts

Likely explanation

Steps to verify on your repl

Observable indicators of sleep

Missing diagnostic detail

Your perspective belongs here.

0 question comments