Tracking whether an IoT device is currently online or offline is a basic requirement of connected-device systems, yet becomes difficult once the handling backend is distributed across multiple stateless processes. A device's connection can move between processes -- during deployments, load rebalancing, or reconnects -- without any real change in its online status, so status cannot simply be derived from connection lifetime. Commonly available tools do not solve this well: TTL-based expiry in stores such as Redis is inherently imprecise, and pub/sub-style notification of state changes is lossy, since a missed broadcast permanently loses the corresponding transition. This paper proposes a design in which stateless nodes coordinate only through a shared, sharded Redis sorted set (ZSET) scored by each device's computed expiry deadline: writes are throttled and batched to keep them off the hot path, and expiry is detected by an independent process that pulls stale entries from the store on a fixed schedule rather than depending on a broadcast. This gives the design a deliberately asymmetric guarantee: an entry is never removed until the runner has attempted to emit its offline event, so a runner that crashes or restarts at any point always has a persisted artifact -- the still-present entry -- to retry emission from, unlike a keyspace or pub/sub notification, which is itself the only artifact and leaves nothing to retry once fired, received or not. An offline transition can therefore never be permanently missed due to the runner's own failures; what happens to an emitted event afterward, downstream of the runner, is an ordinary event-delivery concern this paper does not otherwise address. The corresponding online transition carries no equivalent guarantee, since a narrow crash-plus-reconnect race can still suppress it, a gap the design accepts as self-limiting and recoverable -- on demand by forcing a reconnect, or otherwise via a manual reconciliation fallback -- rather than eliminating it. We derive a worst-case detection-latency bound from the design's tunable parameters, and discuss the iteration of alternative approaches -- native TTLs, in-process maps, timer wheels, and LRU-style structures -- that led to this design. The approach is theoretical: it has not yet been implemented or benchmarked, and its remaining limitations, including continued dependence on a shared external store, are discussed alongside directions for future work.