Live events
Updated 29 September 2026 · applies to 1.0.0 · Commercial
This is a log, not a queue, and the difference is the whole page.
Memcached has no topics, no offsets, no acknowledgement and no delivery guarantees. watch writes
every get, store and eviction on the node to whoever is listening at that moment, and to nobody
afterwards. Nothing is retained. Closing this page ends the subscription, and there is no backlog to
come back to — what happened while you were not watching was kept by no one.
One node at a time
Each node stamps its own line numbers, so interleaving two streams would invent an order the cache never had. The node is chosen, as it is on every other screen in this section, and choosing another one stops the stream and clears the feed.
A node started with -W will not open a stream at all. The screen names the flag and says that only a
restart changes it; the other nodes of the connection are unaffected.
What you can subscribe to
At least one, and any combination:
| Subscription | What it reports |
|---|---|
| Reads | Every get, hit or miss, with the key it asked for. |
| Writes | Every store, with the command used and the TTL it was given. |
| Evictions | Items discarded to make room — the ones a cache under pressure loses. |
| Deletions | Items removed deliberately, which is a different event from an eviction. |
| Connections | Clients arriving and leaving. |
The server drops lines, and nothing measures it
This is the one thing that must never be hidden here. When a watcher cannot keep up, Memcached discards events rather than slow the cache down, and it does so silently — the stream simply has fewer lines in it.
Nothing on the wire says how many were lost. Every line carries the node's own sequence number, shown in the # column, but the node allocates it globally as it logs: entries going to other watchers take numbers out of this run, so a gap is not a loss, and a watcher that genuinely fell behind can receive an unbroken run. BROKA therefore reports no figure for it. The feed can be incomplete, and the screen says so as a standing property rather than as a count.
Two counters sit above the feed:
- Events seen — what arrived.
- On screen — what is in the table now. The newest 300 are kept and older ones fall off, by this page. That is a different loss from the node's.
Reading the feed
Nothing here is retained, acknowledged or replayable. A quiet feed means the cache has been quiet since you started watching, and the screen says that rather than showing an empty table that could mean either.
A stream also ends on its own: after half an hour with nothing to report, or once it has delivered 100,000 events. The line beside Watch says why it stopped — you, the node, the quiet or the limit — and starting it again is how you keep watching.
Use it for the questions a snapshot cannot answer: which keys are actually being asked for, is this node evicting right now or did it evict an hour ago, is that application deleting or is the cache losing things.
For the standing view of the same cache, use Overview and Memory and slabs — those read counters, which survive; this reads activity, which does not.
What is recorded
Opening a stream is audited. It reports the keys your applications are asking for as they ask for them, which is a disclosure in the same sense a key listing is — so the trail records that somebody subscribed, on which node, and to what.
Watching needs the same access as listing keys: write permission on the connection. It changes nothing on the node, so it is allowed in a read-only environment and on a read-only connection.