Notifications
Mobius emits platform events and a routing layer decides where each goes. An event is an incident opened, an IR action pending approval, ingest paused, a connector gone unhealthy, or a billing threshold reached.
Routing rules
In the notifications settings, your organization's admins configure a matrix of event types × channels: for each event type, choose who receives it and whether it notifies in-app on the bell, on a connected channel, or both.
Under Platform rules, toggle which platform events reach you: a workflow started, succeeded or failed, a new environment added, a user invited, billing events such as an invoice paid, an invoice failed or a trial ending, and budget thresholds at 85%, 90% and 100%. Each workflow's own output is routed separately, from that workflow's page.
The Ingestion family covers the ingestion policy and the ingest pipeline for each environment:
| Event | Meaning |
|---|---|
| Ingestion policy changed | An admin saved or restored a policy version, with a summary of what changed. |
| Ingestion policy rejected by Wazuh | The indexer refused the saved policy, for example after a mapping change. |
| Ingestion running a fallback policy | Mobius is ingesting on the last known-good version, or on Critical-only, until a save works. |
| Ingestion policy recovered | The saved policy runs again. |
| Ingestion backlog building | Alerts are arriving faster than the rate limit; they are deferred, not dropped. |
| Ingestion backlog cleared | The backlog has drained. |
| Ingestion paused / stopped | Ingest was paused by an admin, or stopped by the free credit or the budget cap. |
Every event type carries a severity, which drives the color in the bell and the chip in the history: bad news never reads as routine.
Delivery channels
Under Channels, connect where notifications land beyond the in-app bell:
- Slack. Paste the incoming-webhook URL for the channel where notifications should land.
- JIRA. Your JIRA URL, project, email, and API token. Matching events open tickets in that project.
- Email. Notifications and report sharing by email. During the beta, each recipient address is confirmed with us before delivery to it starts.
Only users with the admin role can change integrations and notification settings.
The bell and the history
- The bell shows recent notifications with severity chips. Each one deep-links to the object it is about, whether that is the incident, the environment or the approval. It only carries the latest few.
- The history is the queryable archive: every notification your organization has received, newest first, with the page each one opens. Filter it by family, which is Ingestion, Workflows, Response, Organization, Billing or Budget, search by title or message, and page back through older ones. It is where the bell's View all notifications link takes you.
Recommended baseline
| Event | Route |
|---|---|
| Incident opened at high risk | in-app + email to the on-call |
| IR action pending approval | in-app + email, since approvals are time-sensitive |
| Connector unhealthy or ingest paused | in-app + email to the environment owner |
| Billing thresholds | email to the org admin |
Everything else can stay in-app only. The history keeps it auditable.