The developer added a small in-memory timing trace. During one pause the response had arrived, then the file write occupied the same thread before the display update. That supports the logging suspicion for that occurrence, not every pause.

Can the frozen display still look current? That's a handover problem even before the delay is fixed.

Show the reading's age independently of whether a new reading has arrived, otherwise the display can keep its old healthy-looking colour precisely when it has stopped learning anything.

Don't just switch logging off and call it done. Sorry, I mean that as a limit on any comparison, not something Ravi said he'd done. You still need diagnostics afterwards.

The proposed change writes logs in a background worker with a bounded queue. The display keeps its own update path and shows the age of the last received value. We are testing slow storage before using it as the normal desk monitor.

What happens when the bounded queue fills? Silent lost diagnostics would be a different misleading display.

Give the logger its own health indication, separate from status freshness. A trainer should be able to explain that values may be current while the log has gaps, and that a healthy logger does not prove a fresh controller response.

Also test a slow response with fast storage, so the new age indication isn't only correct when the disk is the thing that fails.

Offline delay tests passed for both paths. Slow writing leaves the display responsive; queue overflow raises a visible diagnostic-gap count. A delayed status response makes the reading age visibly without being relabelled as a new result. The trace still records the separate timings.

Check the ordinary launch and loss of the log destination as well. Those are the conditions the next shift will encounter, without the developer's temporary test setup around it.

Those checks are complete on the desk monitor. An unavailable log destination now shows logging unavailable while the read path continues; a failed read shows no fresh value even with healthy logging. Thanks, Jamie, timing the stages found the shared-thread write instead of leaving us with two competing guesses.