Using UI

Alerts have a full editor in the web app, so you can shape a scope against real spans before arming it. Everything here maps one-to-one onto defineAlert, so an alert built in the UI can be moved into code later (and vice versa).

​

The alert list

Open Alerts from your workspace sidebar. Each row shows the alert’s schedule, whether it is enabled, its latest evaluation outcome, and who last changed it.

• New alert creates an Untitled alert — checked hourly, watching every span, breaching at a 10% error rate — and opens it. It starts disabled, so nothing fires until you arm it.
• New folder groups alerts, the same folders used elsewhere in the workspace. Creating an alert inside a folder files it there.
• Right-click a row (or use its ⋯ menu) to Edit its name, description, and folder, Duplicate it, Move to another folder, or Remove it.

​

Configure the trigger

Open an alert and stay on the Trigger tab. The toggle in the header arms and disarms it, and the name is editable in place. The Scope section switches on the data source you pick:

• Spans gives you the same filter bar as the Spans view — workflow or triggering agent, node kind, integration, connector, action, tool, agent, execution status, free-text search — with a live table of the spans currently matching underneath. That table is the fastest way to tell an over-broad scope from an over-narrow one.
• SQL gives you a query editor with a preview that runs the query and shows the value it returns, so you can confirm the query yields a single number before saving. Remember that a SQL scope must window itself.

Below the scope, set the threshold (metric, aggregation, operator, value), the schedule cron, and the actions to fire on breach. Actions accept a connector action, a tool, or an agent, and their inputs can interpolate the firing’s values — {{alert.url}}, {{event.value}}, {{event.spansUrl}} and the rest.

​

Read the history

The Events tab lists every evaluation, newest first, with its status, the value computed, and the window judged. Filter by status to find just the firings, and expand one to see the runs its actions spawned. See Events for what each status means.

​

Best practices

• Preview before arming — shape the scope against the live spans table, and leave the alert disabled until the numbers look right.
• Match the cron to the signal — short windows catch spikes but are noisier; long windows smooth them out and fire later.
• Watch silence, not just errors — a count / lte alert catches a workflow that stopped running, which no error-rate alert can.
• Make the action say what happened — interpolate {{event.value}} and {{event.spansUrl}} so whoever reads the Slack message doesn’t have to go hunting.

​

Next steps