Status Indicator

A status indicator is a persistent signal of the current condition of something: a record, a connection, a background job, the system itself. Connected. Syncing. Degraded. Expired.

The distinction that decides how to build it: it describes a state, not an event. A toast reports that something happened and leaves. A status indicator says what is true now, and stays true until it is not.

Reporting a persistent condition as a transient message is the common failure. An integration that disconnected is still disconnected five minutes later, and a person who switched tabs when the toast fired has no way to find that out.

Status against its neighbours

Badge and status indicator overlap heavily and the difference is scope: a badge labels a record in a list, a status indicator describes a system or a connection that the whole screen depends on.

Designing the states

Fewer states, mapped to actions. If two statuses lead somebody to do the same thing, they are one status. Products accumulate eleven because the interface is showing the database's enum rather than a decision.

Name them in the user's vocabulary. A state called PENDING_VERIFICATION reaches the screen as "Waiting for approval".

Every state needs a next step or an explicit none. "Degraded" with no indication of what to do, or how long, is an anxiety generator. Either say what somebody can do, or say plainly that no action is needed.

Include time where it matters. "Last synced 4 minutes ago" carries more than "Synced", because staleness is usually the actual question.

Colour is not the signal

A coloured dot alone requires a legend nobody was given, and excludes anybody who cannot distinguish the palette reliably.

Word plus colour. The word carries it; the colour makes it findable.

Shape can help where space is tight — a filled dot, a ring, a cross — but it is a reinforcement, not a replacement for text.

The accessible name must carry the state. A green dot with no text is silent to a screen reader, which means the status does not exist for that user.

Where it belongs

Beside what it affects. A degraded integration should be visible on the screen that depends on it, not only on a status page nobody has open.

Persistent for persistent conditions. A global outage or an expired credential belongs in a banner that stays, not a dismissible message. Something that can be dismissed will be dismissed and then forgotten, and the product spends the next hour behaving strangely for no visible reason.

In the row, for per-record state. A table of jobs needs status in the row rather than in a detail view, because the whole point of the list is scanning for the ones that need attention.

In practice

A product syncs with an external system. When the connection drops, it shows a toast: "Sync failed".

Support hears from customers whose data is days out of date and who had no idea. The toast fired once, at the moment of failure, often while nobody was looking at that screen. Afterwards the interface looks entirely normal — the data is simply old.

The change is to make the condition visible. A status line beside the data showing when it last synced, turning to an explicit warning state when it has been too long, with a reconnect action.

The failure detection did not change. What changed is that the product stopped reporting a lasting condition as a momentary event.

Where teams get it wrong

• A toast for a persistent state. Seen by whoever happened to be looking.
• Colour with no word. A legend nobody received.
• Eleven statuses. A database enum rendered as an interface.
• No next step. Anxiety with no action attached.
• Dismissible for something that still applies. Dismissed, then forgotten, then confusing.
• Status only on a separate page. Nobody has it open when it matters.