Found the write inside the polling loop. No separate timing. I'll add that before blaming the network.

No age shown. Just the value. That's worse than I thought.

Our display once kept a green status through a disconnected cable. Showing the last update time made that obvious; does yours have room beside the value?

Yes. Added age to the draft screen. Timing capture also shows long file writes during two pauses. Status reads weren't slow in those two.

I'd move writing out of the polling path. Give the queue a limit though. An endless backlog just saves the trouble for later.

Who gets told if that queue fills? I do not want to be the person collecting a whole shift of useful diagnostics and finding an empty file at handover.

Show dropped entries explicitly, with the logging fault. Thanks, Theo; I had overlooked that.

And decide whether a full queue drops old entries or new ones. Both lose something. The person reading the log needs to know which history survived.

Developer has a bounded writer queue in the test build. It drops new diagnostic entries when full and shows the count. Slow-folder replay keeps the display updating. Network delay test still outstanding.

That count would help me. Does it stay visible after the folder recovers, or will I need to catch it during the pause?