How do I get an alert on my agent’s run duration?

Rius alerts on run duration with a custom alert on the Duration metric, for example p95(Duration) above 30000 ms over a 15 minute window. You pick an aggregation, a threshold in milliseconds and a window, and optionally scope the alert to one service. When the condition holds, Rius records a firing and delivers it to the channels you attached. Creating the alert is an admin action.

How it works

A custom alert is one or more rules over one shared rolling window. Duration is a numeric metric measured in milliseconds, and it offers these aggregations: avg, min, max, p50, p95 and p99.

• Per-trace values. Numeric aggregations work per trace. avg(Duration) is the average duration per trace in the window, not a total.
• Choosing the aggregation. Use p95 or p99 to catch the slowest runs, max to catch a single outlier, and avg or p50 to watch the typical run. An average hides a few very slow runs, so a percentile is usually the better trigger.
• Comparison. You compare against a number of milliseconds with <, <=, >, >= or ==.
• Filters. Filters apply before aggregation. Scope the alert by Service, Agent, Step, Model, Span kind, Operation, Session or Instance, so a slow batch agent does not trip the alert for your interactive one. With a Step, Model or Span kind filter, Duration measures only the matched spans in each trace, from the first one’s start to the last one’s end, not the whole run. Use Service or Agent to keep whole-run duration.
• Window. The window runs from 5 minutes to 24 hours. A short window reacts fast but is noisy, and a long one is steadier but reacts later.
• Cadence. Rules are evaluated every minute while there is no open firing and every five minutes while one is open, so timings are approximate to that cadence.

A firing opens the first time the condition matches and stays open while it keeps matching. After the condition has stopped matching for two hours, it resolves on its own.

Set it up

1. Open the Alerts page and create a custom alert. See Custom alerts for the full builder.
2. Add a filter for the agent you care about, for example Service equals checkout-agent.
3. Add one rule on Duration. Start with p95, a threshold a little above what your agent normally takes, and a 15 minute window. The builder previews in plain language when the alert fires, and that sentence becomes the alert’s description.

FILTERS   Service = checkout-agent
RULES     p95(Duration) > 30000
WINDOW    15 minutes

4. Optionally add a second rule. Rules combine with AND only, so count(Traces) > 20 next to the duration rule means a slow p95 on a few runs does not page you. For either-or logic, create a second alert.
5. Set Renotify. Off sends one notification per firing. Every N minutes, from 5 to 1440, repeats the notification until someone acknowledges the firing or it resolves.
6. Attach one or more distribution channels (webhook, email or Slack) and save. Saving a change to an alert resolves its open firings and starts the rule afresh.

If you want to know when ingestion stops entirely, add a separate alert with count(Traces) < 1 over a generous window. That rule works as a dead-man switch.

What you get

• A firing in Rius. Each firing records the observed value of every rule against its threshold, so you can see that the duration rule tripped and by how much.
• Delivery to your channels. Every firing goes to each channel attached to the alert. The firing page lists one delivery row per channel with the outcome of each attempt, and each repeat from Renotify adds a row.
• The affected traces. The firing page links the traces behind it, and View all in Traces opens the trace list filtered to the firing’s time window.
• Acknowledgment. A member can acknowledge a firing, which records who saw it and stops further notifications for it. The firing still resolves on its own when the condition clears.
• Optional root-cause analysis. If it is switched on for the alert and the workspace, the firing page also carries an analysis report.

See Alerts for firings, acknowledgment and the lifecycle in full.

When something else fits

• If you want a look at duration without a trigger, the same metric appears as a summary on the Usage and cost view, not as an alert.
• If slowness shows up as the wait for the first streamed token rather than total duration, use the Time to first token metric, which is measured per LLM call.
• If you want to be told about a recurring error, a swallowed error or a tool loop, the pre-defined alerts cover those without building a rule.

Related