Writes are in the polling loop after receipt. We haven't timed their duration yet.

Measure write duration independently of request duration, including the interval until the next poll starts; a slow write can delay future requests without making the completed network request slow.

I'd want that distinction even while diagnosis continues. A frozen value can look like a reassuring constant, particularly to somebody who didn't see the pause begin.

No freshness indication currently. We are adding the successful-read time beside a clear stale-reading state.

Keep that display work separate from the cause claim. It improves what people can interpret, but it won't tell you whether the write or communication delay explains the original pause

If writing moves off the polling path, define bounded buffering and its overflow behaviour as part of the change, rather than replacing an obvious stall with an invisible growing backlog.

Dan, would the overflow warning belong on the current-status display, or only in the diagnostic file? I worry that the people watching one won't necessarily inspect the other.

Both may be needed for different readers, but the record must preserve any gaps independently of a transient screen warning; otherwise later analysis will silently assume a complete history.

Timing found long writes delaying the next poll. Request durations still vary, so we're not declaring the communication question solved.

Has the separate-writer version been tested, or is that still a proposal?

Still proposed. We've agreed freshness wording and are deciding buffer limits and gap reporting with the maintainer.

Then you've located one source of delay and clarified the required behaviour. I'd keep the implementation and slow-destination tests open instead of writing logging fixed in the ticket