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, and View all firings opens the Firings 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.

All firings

The Firings page lists every firing across the workspace’s alerts, most recently seen first. Open is the default and Resolved shows the history; an acknowledged firing stays under Open until it resolves. The Has analysis toggle narrows either list to firings with a root-cause report.

Each row shows the firing and the alert it came from, how many times it matched, when it was first and last seen, its analysis status, and sample traces (three shown, the rest behind +N more). Open firings can be acknowledged from the row with Ack. Click Load more at the bottom to go further back.

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. An open firing with renotify on shows when the next reminder goes out.

Saving a change to an alert’s configuration resolves its open firings and starts evaluating the rule afresh, so a condition that still holds opens a new firing under the new configuration.

A rule that keeps failing to evaluate, for example because its query can no longer run, is detected and stopped automatically, and the failure is recorded. One failing rule never holds up the others.

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.

Root-cause analysis on demand

Admins can run an analysis for any firing with Run analysis on the firing page, whatever the alert’s switch says and without waiting for the cooldown. It counts as one analysis against the budget.

Analyses draw on a monthly budget, shown in the Intelligence section of Settings → Workspace as used of allowed, with the date it resets. Past the budget, firings are not analyzed and show Over budget. A firing whose analysis was accepted but never reported back shows No report.

Analysis status

The Firings list and each firing’s page show where its analysis stands:

A firing that was never analyzed shows a dash. Run analysis is not offered while an analysis is queued or running, or on a firing that already has a report, is over budget, or is over allowance.

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.