From 9d2b99c1f5244184de864756f448ac13d3090cb1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mat=C4=9Bj=20Pavl=C3=AD=C4=8Dek?= Date: Tue, 16 Jun 2026 11:00:58 +0200 Subject: [PATCH] valkey: add reconnect note --- apps/docs/content/valkey/overview.mdx | 28 ++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/apps/docs/content/valkey/overview.mdx b/apps/docs/content/valkey/overview.mdx index 13412c31..6cbf170e 100644 --- a/apps/docs/content/valkey/overview.mdx +++ b/apps/docs/content/valkey/overview.mdx @@ -85,7 +85,33 @@ Valkey requires a password. It is generated automatically, exposed as the sensit Services created **without** a `password` variable (older deployments) keep working without authentication and are unaffected. **All deployments created since this release require the password.** ::: -Idle connections are closed after 5 minutes of inactivity. Use a client connection pool or TCP keep-alive if your application holds long-lived idle connections. +### Idle connection timeout + +Valkey closes connections that stay **idle for 5 minutes** (`timeout 300`). This is intentional on the managed instances — we avoid keeping infinite idle connections open. Older Valkey services ran with no timeout (`timeout 0`); if you connected before this change, your connections used to stay open indefinitely. + +"Idle" means **no commands sent on the connection** — the server resets the timer on every command, so a busy connection is never closed. The connections most likely to be affected are long-lived ones that sit waiting rather than sending commands, typically **pub/sub subscribers** and **blocking reads** (`BLPOP`, `XREAD`, …). Most clients reconnect automatically, so you may only see log lines such as `Redis subscriber socket closed; reconnecting if possible.` — but the reconnect churn can drop pub/sub messages published in the gap. + +To keep idle connections open, send an application-level **`PING` on an interval shorter than 300s**. A TCP keep-alive alone is **not** enough — keepalive packets live below the application layer and don't count as Valkey commands, so they don't reset the idle timer. + +Many clients have a built-in option for this. For example, [node-redis](https://github.com/redis/node-redis): + +```js +const redisClient = createClient({ + url: redisURL, + pingInterval: 10000, // send PING every 10s; keeps the connection under the 300s idle limit +}); +``` + +If your client has no equivalent option, run your own heartbeat on every long-lived connection: + +```js +const heartbeat = setInterval(() => { + publisher.ping().catch(() => {}); + subscriber.ping().catch(() => {}); +}, 60000); // any interval under 300s +``` + +For ordinary request/response traffic, a [connection pool](https://valkey.io/topics/clients/) that recycles connections handles this transparently. ## Persistence