Paused Is Not Empty: A Status Contract for Operators

A dashboard that shows 'Queue: 0 active' can mean two very different things. Either there is nothing to do, or work is waiting and a switch is off. An operator who reads the first as the second may leave customer requests sitting unattended. This article proposes a status and action contract that keeps those states apart. It is a design recommendation with a hypothetical example.

The primary artifact: the contract

The status shown to an operator is computed from three independent facts, never from one combined number:

Switch: running or paused (set by a person or a rule).
Waiting: count of items ready to be processed.
In flight: count of items already started.

From these, the screen shows one of five statuses, each with a sentence, a colour that does not rely on hue alone, and a permitted action set.

Running, idle. Waiting 0, in flight 0. Sentence: 'Running. Nothing waiting.' Actions: pause.
Running, busy. Waiting above 0 or in flight above 0. Sentence: 'Running. 14 waiting, 2 in flight.' Actions: pause.
Paused, with work waiting. Waiting above 0, switch paused. Sentence: 'Paused. 14 waiting. Nothing new will start.' Actions: resume, and view waiting items.
Paused, draining. Paused, in flight above 0. Sentence: 'Paused. 2 still finishing.' Actions: resume; no cancel unless separately designed.
Paused, empty. Waiting 0, in flight 0. Sentence: 'Paused. Nothing waiting.' Actions: resume.

Statuses 3 and 4 can both be true at once. In that case show both sentences, waiting first, because waiting items are the ones at risk of being forgotten.

Worked example (hypothetical)

At 10:00 the queue has 16 items: 14 ready and 2 in flight. An operator pauses it. Expected screen: 'Paused. 14 waiting. Nothing new will start. 2 still finishing.' At 10:03 both in-flight items complete. Expected screen: 'Paused. 14 waiting. Nothing new will start.' The count 14 is unchanged because pausing does not remove or hide waiting items. New enquiries that arrive while paused raise the number: after 5 arrive, the screen reads 19 waiting, and 14 plus 5 equals 19.

At resume, the status becomes 'Running. 19 waiting, 0 in flight', then the count falls as items start. The item that was waiting longest should be visible, for instance 'oldest waiting: 3 hours', so the operator can judge urgency.

Making the pause itself visible

Record who paused, when, and an optional reason. Show the elapsed time of the pause on the status line. Consider an expected resume time set by the operator, and a reminder to the pausing role if that time passes while items still wait. A pause without an owner is a likely source of forgotten work.

Failure branches

If the count cannot be read, show 'Unknown' instead of 0. A zero from a failed read looks exactly like an empty queue.
If the switch state cannot be read, show 'Unknown' and offer no resume or pause action that could act on stale information.
If an action is clicked and the result is unclear, for example a timeout, show 'Pause requested, not confirmed' and do not automatically repeat the call. Re-read the state and let the operator choose.

Stop conditions

Stop treating the screen as reliable if the counts and the item list disagree, for example the counter says 14 but the list shows 12. Flag the mismatch rather than choosing one.

Acceptance tests (proposed, not performed)

Set switch paused, waiting 14, in flight 0. Expect the paused-with-work sentence and no phrase like 'empty' or 'idle'.
Set switch running, waiting 0, in flight 0. Expect running idle.
Set paused, waiting 0, in flight 0. Expect paused empty, still labelled paused.
Add 5 items while paused. Expect waiting 19 and the oldest-waiting age to remain unchanged.
Force the count read to fail. Expect 'Unknown', never 0.
Force a pause request timeout. Expect an unconfirmed message and exactly one request sent.
Review the screen with colours removed. Expect each status still distinguishable by text.