Pre-defined alerts
Rius ships curated detectors for the failure shapes agents actually exhibit. Each has a details page with a plain-language description of exactly when it fires, a small set of configuration knobs, its attached channels, and its firing history. You cannot delete a pre-defined alert, only disable it. To point one at part of your workspace with its own settings, see Narrow a pre-defined alert.
Consistent Error Pattern
Errored spans are grouped by service, step, and normalized error message. A group fires when it reaches the configured number of errored spans across the configured number of distinct traces within the rolling window: the same error, in the same service and step, failing repeatedly across runs.
A single trace retrying the same step never fires on its own, and spans with an empty error message never alert.
Problems this is built to catch:
- An expired or rotated provider credential: every model call in one service starts failing with the same 401, run after run.
- A deploy that broke one step: the same
KeyErrorfrom the same tool in every run since the rollout. - A rate-limited or degraded upstream: the same 429 or timeout recurring across runs while everything else stays green.
| Knob | Default | Meaning |
|---|---|---|
| Time window | 5 minutes | The rolling window each group is measured over |
| Errored spans | at least 3 | Failures of the same error within the window |
| Distinct traces | at least 2 | Separate runs the failures must span |
| Renotify | off | Repeat the notification every N minutes while the firing is open and unacknowledged; off sends it once |
Swallowed Error
Fires when a step inside a run errored but the run still reported success: the trace’s root span finishes OK while at least the configured number of child steps that are not tool calls ended with an error. The error was caught and swallowed somewhere between the step and the root, so the run looks successful.
Errored tool calls do not count. A failed tool call is returned to the model as the tool’s result, so the agent saw the failure and could act on it.
Problems this is built to catch:
- A model call inside the run fails and the code falls back to a canned answer instead of surfacing the error.
- Retries are exhausted and the code falls back to a cached value rather than failing loudly.
- A sub-agent in a multi-agent pipeline crashes and the orchestrator ships whatever partial answer it already had.
One firing per run. Only finished traces are evaluated, so an in-flight run never fires early.
| Knob | Default | Meaning |
|---|---|---|
| Time window | 5 minutes | The rolling window finished traces are scanned over |
| Errored spans | at least 1 | Errored child spans, not counting tool calls, inside one run. Set it through the MCP server as min_errored_spans; the details page doesn’t offer it |
| Renotify | off | Repeat the notification every N minutes while the firing is open and unacknowledged; off sends it once |
Formerly called Silent Failure: the MCP server still accepts
silent_failure for this alert, and always answers swallowed_error.
Tool Loop
Fires when the same tool is called with identical parameters at least the
configured number of times in a row inside a single trace within the window.
Repeated identical calls are the signature of an agent stuck in a loop: it
is no longer making progress, just burning tokens. Calls count as identical
when the tool name and normalized arguments match. Only spans of kind TOOL
count, so a tool function traced with a bare observe (a CHAIN span) is
never part of a loop; trace it with the TOOL kind.
The identical calls must form a run: taken in start order, at most one other tool call sits between neighboring repeats. A tool the agent comes back to after doing other work is routine, not a loop, and does not fire. Calls whose arguments were not captured, for example with content capture off, are never counted as identical.
One firing per trace and tool.
Problems this is built to catch:
- An agent repeating the same search with the same query because no result ever satisfies its stop condition.
- A broken tool schema: the model retries the identical call expecting a different outcome, and never gets one.
- A planner and executor cycling on the same lookup, making no progress while the token bill grows.
| Knob | Default | Meaning |
|---|---|---|
| Identical calls | at least 3 | Same tool, same parameters, in a run inside one trace. 3 is also the minimum |
| Time window | 10 minutes | How far back calls within the trace are counted |
| Renotify | off | Repeat the notification every N minutes while the firing is open and unacknowledged; off sends it once |
A Tool Loop alert saved with 2 identical calls, the earlier minimum, now works as 3.
Narrow a pre-defined alert
A narrowed version is a copy of a pre-defined alert that only watches what its filters match, for example error patterns in one service. Use one when a part of your workspace needs its own thresholds or its own delivery: a noisier service with a higher bar, or a critical step whose firings go to a dedicated channel.
Consistent Error Pattern and Swallowed Error can be narrowed. Tool Loop cannot. The filters each one accepts:
| Alert | Filters |
|---|---|
| Consistent Error Pattern | Service and Step of the errored span |
| Swallowed Error | Root service, the service of the run’s root span |
To create one, open the alert’s details page and click Narrow this alert under Narrowed versions. This is an admin action. Give it a name and its filters, then tune it on its own page.
A narrowed version is a separate rule:
- It has its own page, knobs, attached channels, and firings, listed under Narrowed versions on the original alert’s page.
- It counts against your plan’s alert-rule limit, like a custom alert.
- Changing its filters resolves its open firings, because it now watches something else.
- The original alert keeps running as before, unless you disable it.
Context rot
A fourth detector watches the context window of your agents: calls that run almost full, one tool’s results taking over the context, history that was lost or compacted, and output cut off at the token limit. It has its own page because it needs your agents to send more than errors: Context rot.
Next steps
- Context rot: the fourth pre-defined detector, for full, compacted, and truncated contexts.
- Custom alerts: thresholds on cost, tokens, latency, and errors that the pre-defined set does not cover.
- Distribution channels: route firings to webhook, email, or Slack.