The bell in the workspace header carries your unread count for the workspace you are in, plus anything addressed to your account. "See all" opens the full inbox, where rows can be filtered by kind, category, urgency and whether they are read.
Both update as things happen — a row raised while you are looking at the page appears without a refresh.
Opening the bell marks nothing read. Only clicking a row, or "Mark all read", does.
That is not fussiness about counters. Reading a notification cancels its pending email: the message was on its way, you have now seen it, so it is called off. If glancing at the popover counted as reading, a look at 9am would silently cancel every email queued behind it — and the person who then got distracted would never hear about any of them again.
| State | What it means | Who sets it |
|---|---|---|
| Read | You have seen it | You |
| Resolved | The condition it described has ended | KonnectHub |
| Dismissed | The row is gone | You |
Resolved is the interesting one. When a failing deployment recovers or a broken connection starts working, the original row is not deleted — it is marked resolved, drops out of your unread count, and stays in the list drawn as settled. A separate recovery notification arrives alongside it. What you are left with is the shape of the outage: when it started, how many times it happened, when it ended.
Because of that, a still-open row keeps collapsing new occurrences into itself with a count, while a resolved one never does — the next occurrence starts a fresh row, and a new row is exactly the signal that this is a new incident.
Dismissing deletes the row. You can dismiss something that is still unresolved — you have decided you do not care — and it will come back as a new row if the problem happens again. "Clear read" dismisses everything you have already read.
Rows that are both read and resolved are eventually tidied away (after 90 days by default). Anything unread, or still open, stays until you act on it. Deleting an unread alarm is the one thing this system will not do.
Notifications do not widen anyone's access. A row that names a flow and quotes an error is only sent to people whose permissions let them read that in the first place, and the same filter runs before the email leaves rather than at the moment you open your inbox. Somebody who cannot see a workspace's executions does not get told about its failing deployments — by any channel.
Notifications about you personally — your role changed, you were removed from a workspace, your token is expiring — carry no such gate, because they are addressed to you and describe nothing else.
The bell is strictly scoped to the workspace you are in. The workspace switcher carries a dot against any other workspace with something unread, so an alert somewhere else still gets your attention without one workspace's chrome ever showing another's contents.