Alerts
Fire a notification when a finished trace crosses a threshold you set, delivered to email or an existing webhook endpoint.
An alert rule watches finished traces. When a trace is compacted, every enabled rule whose filters match is evaluated against that trace’s summary, and a rule that trips delivers to email or to a webhook endpoint.
A rule
| Field | Values |
|---|---|
metric | error_count, error_rate, latency_ms, cost_usd, score |
operator | gt, gte, lt, lte |
threshold | Any finite number |
destinationType | email or webhook |
destination | An email address, or an existing webhook endpoint ID |
appId, environmentId, service, model, release | Optional filters |
enabled | Defaults to true |
error_rate is a percentage, so a threshold of 5 means five percent.
cost_usd and score are skipped when the trace has no known value, so a rule
on either does not fire on zero.
Deduplication
An occurrence is keyed on (alertRuleId, traceId, traceRevision), so a trace
re-compacted at the same revision cannot fire the same rule twice. This is a
per-trace guarantee, not a rate limit: tighten the filters, not the threshold,
when a rule is too noisy.
Alerts versus webhooks
An alert rule fires on a finished trace crossing a threshold. A webhook endpoint fires on every event matching a type filter. Most teams use both: webhooks for a raw feed, alerts for the things that should interrupt someone.
Related
- Get notified when your agent fails, the full recipe
- Alerts API
Usage & dashboards
Slice telemetry by any dimension your app emits in the Usage explorer, then save a dashboard tailored to your business — built by you, or authored by your coding agent over MCP.
Moderation
Rules that inspect the content flowing through your agents, and the violations they raise, from a keyword or regex match to a built-in detector.