Alerts

Alerts watch your workspace and notify you when something needs attention: a recurring error, a run that silently failed, an agent stuck in a loop, or a metric crossing a threshold you set. You configure what to watch and where to deliver; Rius evaluates continuously and records every firing until you acknowledge it.

Configuring alerting is an admin action: creating, editing, enabling, or disabling alerts, the workspace-wide alerting switch, and everything about distribution channels. Members see the alerts and their firings, and can acknowledge a firing. See Roles and permissions.

The Alerts page

The page has four sections:

• Pre-defined alerts: curated detectors Rius ships, including Consistent Error Pattern, Silent Failure, and Tool Loop. Enable or disable each one and tune its thresholds on its details page.
• Custom alerts: rules you build yourself on workspace metrics, scoped by filters.
• Distribution channels: where firings get delivered, including webhook, email, and Slack.
• Recent firings: the newest firings across every alert, newest first. Clicking one opens the firing’s own page.

Firings and acknowledgment

A firing is one occurrence of an alert’s condition. Each alert’s details page lists its firings with open ones first. Acknowledging a firing marks it handled with your name and time; acknowledged firings stay in the list, dimmed, so the history remains auditable.

Clicking a firing opens its own page with the full picture: when it opened, when the condition was last seen, the affected traces, each linked to the trace view, and the delivery list, one row per channel the firing was sent to with the outcome of each attempt. When root-cause analysis is on, the page also carries the analysis agent’s report: what failed, since when, and its reading of the cause, written back as soon as the run completes. View all in Traces opens the trace list pre-filtered to the firing’s signature and time window.

While an alert is enabled, every firing is delivered to each channel attached to that alert. Disabling an alert stops evaluation; its open firings stay as they are until you enable it again.

Firing lifecycle

A firing opens the first time an alert’s condition matches and stays open while it keeps matching; last seen moves forward with each match. Once the condition has stopped matching for two hours, the firing resolves on its own and drops out of the open list; if the same condition comes back later, that is a new firing, unacknowledged. Acknowledging a firing does not close it: it records who saw it and stops any further notifications for it, and the firing still resolves on its own when the condition clears.

Rules are evaluated every minute while they have no open firing, and every five minutes while one is open, so timings are approximate to that cadence.

Each alert has a Renotify setting for how often to repeat the notification while a firing is open and nobody has acknowledged it: off, the default, sends one notification per firing; every N minutes, from 5 to 1440, repeats it on that interval until the firing is acknowledged or resolves. Each repeat appears as a row in the firing’s delivery list.

The Alerting switch at the top of the page is the workspace-wide master switch. Turning it off pauses detection and notifications for every alert at once, without touching each alert’s own enabled state; turn it back on and the alerts resume exactly as they were configured. Use it for a planned migration or a noisy incident, when you want silence without unpicking individual rules. It is an admin action.

Each alert also has a Root-cause analysis switch. When it is on and the workspace has root-cause analysis enabled, every firing of that alert is handed to the analysis agent; see Root-cause analysis for the workspace-level setting.

Next steps

• Pre-defined alerts: what each detector fires on, and its knobs.
• Custom alerts: build your own rules on workspace metrics.
• Distribution channels: webhook payloads, email, and the Slack app.