Ongoing problems need to persist, not flash once
Aliases: ongoing incident · standing failure · persistent global
What it is
Some content on the global channel is a problem that is still happening: payments down, the search index damaged, mandated maintenance not yet over. A one-shot notice—a flash that vanishes, or a line that appears only in the first second after launch—treats an ongoing problem as an event already told. Ten minutes later the user tries to pay; the world has changed and the interface pretends it has not. Persistence is not a louder tone. It exists because the problem’s lifetime has not ended; when the problem ends, the notice ends.
Why it happens
People habituate quickly to a warning they file as “already seen,” which is the right move for an event. An ongoing problem does not need to be reminded once more; it needs to remain environment before every later related action. A one-shot hits only whoever was present; anyone who arrives later, returns from background, or switches device never receives it. Worse, people who saw it once use that memory against the later UI: maintenance must be over by now, so they tap pay again. Persistence takes “this is still true” out of memory and pins it on the shared slot, so later actions still collide with the constraint. It depends on the state remaining true, not on replaying the same sentence.
Where it stops holding
A problem that has ended but still occupies the global slot trains people to ignore global notices, including the next real incident. An intermittent fault (a gateway that blips) will, if each blip inserts a standing notice, flicker the slot between present and absent, which is harder to use than a steady “unstable.” A standing notice about a background capability the user is not in becomes task-irrelevant noise; show it when they enter that capability. Some security problems (a dead session) must interrupt rather than sit quietly, which is already past notice and into forced re-authentication.
Applying it
- Model a global problem as a state machine with a start and an end: appear at start, remove at end; do not broadcast only at launch.
- A short constraint beside a related action is fine, but it does not replace the still-true state in the global slot.
- Record start and end, and write copy that distinguishes “happening now” from “recovered.” Recovery may get a brief confirmation; do not make the recovery message persistent too.
- Verify by leaving the app for ten minutes while the problem still holds, or by entering from another door. If the constraint is gone, an ongoing problem was shipped as a one-shot event.