# Notifications

> Read the header bell and toast alerts — the event catalogue NotificationCenter surfaces, what it deliberately stays silent on, and why it isn't a persistent log.

**NotificationCenter** is the bell icon in the header, with an unread-count badge.
Clicking it opens a panel listing recent system events (newest first), with **Mark
all read** and **Clear all** actions. Some of the same events also raise a brief
toast — a transient banner in the corner of the screen — so you notice them even with
the panel closed.

## What raises a notification

- **Inference started** — inference reaches the running state.
- **Inference fault** — inference stops on a real error (`InferenceFaulted`). Repeat
  faults for the *same* datasource, while the prior alert is still unread, replace it
  (refreshing the timestamp) instead of stacking duplicate entries; once you read one,
  the next fault for that datasource creates a fresh entry. This one is Center/badge
  only — it deliberately does not also toast, since the blocking fault banner elsewhere
  in the UI already surfaces it, and a second popup would be redundant.
- **Involuntary inference stop** *(v1.28.1)* — a Warning-level alert when inference
  stops for a reason you did not directly request:
  - a different datasource superseding it (singleton takeover),
  - the active datasource being **deleted**,
  - its **tags being replaced**, or
  - its **config being edited** while it was running.

  These ride the existing severity-driven log→alert pipeline rather than a new event
  type — the backend logs them at Warning, and the same path that surfaces warn/error
  log lines below picks them up.
- **Model activated** — a model is now the active one for its datasource.
- **Model upload failed** — an uploaded model failed validation, with the reason.
- **Warning/error log entries** — only `warning` and `error` level log lines ever
  surface here; `info`/`debug` never do. A rate limiter throttles a burst of
  warning/error log lines so a noisy fault doesn't flood the panel — the limit is a
  shared window across all of them, not per distinct message, so an unrelated warning
  arriving during a burst can also be throttled (this includes the involuntary-stop
  alert above, since it rides this same log path). These are Center-only (no toast), by
  the same anti-spam design as the fault dedupe above.
- **Output write failures** *(v1.26.0)* — a sink rejects a write (for example, an
  MQTT ACL denial or a disconnected broker), reported with the failure count and
  reason.

## What is deliberately silent

Some events are intentionally **not** notified, so the panel stays signal, not noise:

- **Operator-initiated stops** — clicking Stop, or disabling the datasource, do not
  raise an alert. Only a stop you didn't ask for (see above) does.
- **Service shutdown** — logged at Info and stays silent, same as any other
  Info-level line.
- **High-frequency streams** — routine, expected traffic is never notified regardless
  of rate.
- **Realtime reconnection recovery** — losing the realtime connection raises a
  warning ("Realtime connection lost"), but successfully reconnecting afterward is
  treated as low-value noise and is suppressed.

**In-memory only — not an audit log**

The notification list lives in the browser's in-memory cache, capped at the most
recent entries, and **clears on page reload**. It's a real-time attention aid, not a
persistent history: it does not survive a refresh, isn't stored server-side, and
should not be treated as a compliance or audit trail. For a durable record, use the
system's own logs.

## If something goes wrong

- Missing an alert you expected, or seeing unexpected warnings — check the
  [Troubleshooting](/troubleshooting/) runbook.

## Next steps

  - [Monitor predictions](/operate/monitoring/) — Latency, throughput, and KPIs once a datasource is streaming.
  - [Troubleshooting](/troubleshooting/) — Symptom-first runbook for common issues.