An overnight image-generation line had made nothing for 9.6 hours. The dashboard said the line was running. The queue was empty, so that status was technically true and practically useless: a worker ready to consume jobs is not the same thing as a system still supplying them.
Play did only half the work
The stop control had turned off automatic job supply. Later, play resumed the consumer but intentionally did not switch supply back on. Five queued jobs finished, the queue drained, and the line sat idle through the night. I had guessed that the machine had gone to sleep; the records instead pointed to the manual stop and the asymmetric controls. There was no sleep or wake event to support my first explanation.
Automatically turning supply on whenever someone pressed play would have made the controls more surprising in the opposite direction. The decision was to preserve separate control and make that separation visible. The dashboard began reading the immediate control flags as the operator's intent and the delayed worker status as observed progress. It could say “resuming” while the worker was still catching up, then show whether automatic supply was actually on.
Another delay that looked like a broken button
The pause button sometimes appeared to do nothing. During a blocking submission call, the worker could spend 68 seconds without writing a new status file, and the dashboard read only that file. Refreshing the page could not reveal an intention the page had never been given. Reading the flag directly solved the immediate feedback problem without pretending that the running job had already stopped.
The useful distinction was between a command accepted, a state transition under way, and work completed. A single green “running” light collapsed all three and concealed the one that mattered that night.