Alerts & notifications
Alert rules, the account spend cap, and the channels notifications deliver to.
The Alerts page watches spend across every project and tells you — on the channels your team actually reads — when something needs attention. Alerts notify; they never block a call. Enforcement lives in a project's budget mode, not here.
Alert rules
You can create six kinds of rule, each from New alert:
| Rule type | Fires when |
|---|---|
| Budget threshold | A project's spend crosses a percentage of its budget. |
| Forecast overrun | The projected end-of-month spend exceeds a dollar amount. |
| Runaway run | One agent run exceeds a spend cap, or makes more than a given number of calls inside a window. |
| Scoped budget | Spend on one model, provider, agent run, or tag pair crosses its own limit. |
| Daily spend anomaly | A day's spend jumps beyond a multiplier of the recent norm. |
| Unit cost anomaly | The cost per request drifts beyond a multiplier of its baseline. |
Alongside the rules sits the pinned account spend cap — one account-wide monthly notification cap across all projects. It is available on Production and above.
Create a rule
- Open Alerts and select New alert.
- Pick the rule type from the six cards.
- Set its condition — the percent, dollar amount, cap, or multiplier and lookback.
- Pick delivery channels, or leave the project's defaults.
- Create alert.
Runaway run
A runaway-run rule watches every run in a project. Set a run spend cap (USD, whole cents, up to $1,999,999.99) and, optionally, a call threshold together with a window of 1–1440 minutes. Its mode decides what happens at the cap: alert_only (the default) notifies; hard_deny also denies the run's further calls, which the SDK surfaces as a BudgetExceededError with budget_period="agent_run". A rule fires at most once per run per UTC day.
A firing runaway alert carries a Stop run button in the activity sidebar. Pressing it does what the Agents tab's Stop does — denies every future check for that run, revokes its leases, and ends it permanently — so the response to a runaway is one click from the notification. See Agent runs.
Scoped budget
A scoped-budget rule caps one slice of spend: choose the scope (Model, Provider, Agent / run, or Tag), the exact match (a model id, provider name, or run id — or, for Tag, the key and value), a limit, and a per-rule mode. A hard_deny scoped rule denies matching calls even on an alert_only project. See Scoped budgets.
Rule states and actions
Each rule shows one of four states: Firing, Approaching, Snoozed, or Calm. From a rule's row or drawer you can Snooze it (silence until a time you pick), Pause it (off until you resume), Edit it, or Delete it.
The rule drawer
Selecting a rule opens a drawer with the context you need to act: this period's spend, a by-model breakdown, cap editing in place, the rule's firing history, linked alerts, a suspected cause, and unit economics for anomaly rules. The activity sidebar on the Alerts page lists recent firings across all rules.
Notification channels
Notifications deliver to reusable channels plus two account-level targets. This page's Settings → Notifications section is where all of them are configured.
The five reusable channel types — Slack, PagerDuty, Microsoft Teams, Discord, and Telegram — are created once in Settings → Notifications with Add channel, verified with each channel's Test button, and then referenced by any alert rule or project delivery default.
Email is always available and always on — it delivers to your account address and needs no setup.
SMS is offered in the US and Canada. Enabling it takes three things: an eligible plan (Production and above), a verified phone number (6-digit code), and an explicit SMS-alerts consent toggle.
Channel availability is tier-gated: the Free tier delivers to email only, and only for budget events; Production and above unlock webhooks plus the five reusable channel types and SMS, with every event type available on every channel. See Plans & billing.
Provider-health events
Circuit-breaker opened and closed events are delivered today on paid plans (Production and above). They are not rules you create — they are driven by breaker state reporting from the SDK (v0.3.0+), scoped to a single project, provider, and SDK instance, and they arrive through webhook subscriptions and each project's delivery-defaults rows (see webhook events). They do not appear in the alerts feed on this page, which stays budget-only.
Two details worth knowing: a circuit_breaker_closed event is info-severity but bypasses a project's severity floor, so a breaker that opened can always be closed out; and because each SDK instance reports its own in-process breaker, one instance opening does not mean the provider is down everywhere. provider_outage and provider_recovered remain defined in the contract but are not yet emitted.