> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getcargo.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Using UI
> Build an alert visually — pick the spans it watches with a live preview, set the threshold, and read its firing history.
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`](/alerts/overview), 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](/folders/overview) 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.
Duplicating is the quickest way to fan one alert out across workflows: the copy
keeps the original's scope, threshold, schedule, and actions, and starts
disabled so it can't fire before you have retargeted 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](/alerts/overview#sql-scope).
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](/alerts/overview#actions-what-fires-on-breach).
An alert's window starts where its last evaluation ended, not at a fixed
lookback — so the cron is effectively the window size. Widening the cron from
`@every 5m` to `@every 1h` makes each evaluation judge an hour of spans, which
changes what a percentage or a percentile actually means.
## 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](/alerts/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
The `defineAlert` reference — scopes, metrics, actions, and the evaluation
window.
Statuses, snapshots, and the runs a firing spawned.
Runs, batches, spans, and traces from the terminal.
Batch-health thresholds and alert actions on a play.