How does Rius detect a consistent error pattern in AI agents?

Rius detects a consistent error pattern with its pre-defined Consistent Error Pattern alert, which fires when the same error keeps failing in the same service and step across separate runs. By default, that means at least 3 errored spans across at least 2 distinct traces within 5 minutes. You can narrow it to one service or step, and you can turn it off, but you cannot delete it. It is one of the detectors on the Pre-defined alerts page, part of Alerts.

How it works

Rius groups errored spans by three things: the service, the step, and the normalized error message. It measures each group over a rolling time window. A group fires when it reaches both thresholds inside that window:

• Errored spans: the number of failures with the same error. The default is at least 3.
• Distinct traces: the number of separate runs those failures must span. The default is at least 2.

The window defaults to 5 minutes. The alert looks for the same error, in the same service and step, failing repeatedly across runs.

Two cases never fire:

• A single trace retrying the same step does not fire on its own, because the failures must span more than one run.
• Spans with an empty error message never alert.

The alert is built to catch failures like these:

• An expired or rotated provider credential, where every model call in one service fails with the same 401, run after run.
• A deploy that broke one step, where the same KeyError comes from the same tool in every run since the rollout.
• A rate-limited or degraded upstream, where the same 429 or timeout recurs across runs while everything else stays green.

Set it up

1. Send traces from your agent so there are errored spans to group. The shared setup is one call:

   import rius
    
   client = rius.init(
       api_key="ri_...",
       service_name="my-agent",
   )

2. Open the Consistent Error Pattern details page. It describes in plain language exactly when the alert fires and shows its knobs:

   • Time window: 5 minutes by default.
   • Errored spans: at least 3 by default.
   • Distinct traces: at least 2 by default.
   • Renotify: off by default. When you set it, Rius repeats the notification every N minutes while the firing is open and unacknowledged. When it is off, Rius sends the notification once.

3. Attach the channels that should receive firings: webhook, email or Slack.

4. To give one part of your workspace its own thresholds or its own delivery, click Narrow this alert under Narrowed versions on the details page. This is an admin action. Give the copy a name and filter it by the Service and Step of the errored span. A noisier service can get a higher bar, and a critical step can send its firings to a dedicated channel.

5. To stop the alert, disable it. Disabling is the only option, because a pre-defined alert cannot be deleted.

What you get

• A firing when one error repeats across runs in one service and step, not when a single run retries.
• Thresholds you can tune: the window, the number of errored spans, the number of distinct traces and renotify.
• Narrowed versions of the alert, each with its own page, knobs, attached channels and firings, listed under Narrowed versions on the original alert’s page.

Keep these points about narrowed versions in mind:

• A narrowed version is a separate rule and 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.

When something else fits

• If an error is caught inside a run and the run still reports success, Swallowed Error is the better fit. If an agent calls the same tool with identical parameters over and over, use Tool Loop.
• If you need thresholds on cost, tokens, latency or error rate rather than a repeated error, use custom alerts.

Related