KVS connection monitor

pod kvsmon-6d87d75c44-c9g25 · egress IP 5.148.184.24 · running 4660s · 2026-08-05T16:35:47Z
targets: public → rediss://kvsmon-redis.00e40d6.keyvaluestore.nineapis.ch:6379
SVC-114637 — looking for idle-flow resets on the deplo.io → KVS path. Each row is one dedicated long-lived connection. idle@drop is how long the flow had been quiet when it was killed — that number is the intermediary's idle timeout.

Probes

probestatedoingupidledrops conn.failidle@drop minmedmaxlongest life peerlast error
public/stream-blockupblocked_read4660.1s160.0s00178.209.60.11:6379
public/stream-block-kaupblocked_read4660.1s160.0s00178.209.60.11:6379
public/ping-60upidle4660.1s39.9s00178.209.60.11:6379
public/ping-180upidle4660.1s160.0s00178.209.60.11:6379
public/ping-300upidle4660.1s160.0s00178.209.60.11:6379
public/busyupbusy4660.1s0.6s00178.209.60.11:6379
public/busy-pingupbusy4660.1s0.3s00178.209.60.11:6379
public/stream-block: XREADGROUP BLOCK 900s, no TCP keepalive — same shape as Symfony Messenger · public/stream-block-ka: same, but SO_KEEPALIVE with 30s idle — tests whether client keepalive prevents the drop · public/ping-60: idle 60s between PINGs — drops here bracket the intermediary's idle timeout · public/ping-180: idle 180s between PINGs — drops here bracket the intermediary's idle timeout · public/ping-300: idle 300s between PINGs — drops here bracket the intermediary's idle timeout · public/busy: 1024B SET+GET every 1s, never idle — the counter-test: if this drops too, the cause is not an idle timeout and the search moves elsewhere · public/busy-ping: PING every 1s — active but carrying no data. Paired with `busy` it separates 'the flow is active' from 'the flow is moving data'

Incidents (newest first, last 100)

time (UTC)probeeventduringidlealive error classerror
no drops recorded yet
This page shows this pod only and is lost on restart. The durable record across all replicas is on stdout, one JSON line per event: nctl logs app kvsmon -p josi --follow