BrowserStack AI Evals
Monitoring

Alerts

Define metric-based alert rules over traces and sessions, and get notified via webhook, email, or Slack when thresholds are breached.

Alerts

Alerts watch your project's metrics — latency, cost, token usage, error counts, and evaluation scores — and notify you when they cross a threshold. Each alert has a rule (what to watch) and one notification channel (where to send it).

How alerts work

  1. You define a rule: a metric, an aggregation, a comparison operator, a threshold, and a look-back window.
  2. The evaluator runs on a schedule, querying your project's traces or sessions over the window.
  3. If the aggregated value breaches the threshold, an alert event is created and the notification is dispatched.
  4. After firing, the rule enters a cooldown — it will not fire again for that duration even if the condition still holds.
  5. Events progress through three states: Firing → Acknowledged → Resolved.

Opening Alerts

Open Alerts under the Observability section of the left sidebar. The page has two tabs:

  • Alert Events — every event the alert engine has produced, with current state and notification delivery status.
  • Alert Rules — every rule you've configured. Toggle enabled, edit, or delete from here.

Alerts page with Alert Events and Alert Rules tabs

Click Create Alert at the top right to open the rule editor.

Create an alert

Name and description

  • Name (required) — must be unique within the project. Example: High latency on chat agent.
  • Description — optional free text to remind future-you why the rule exists.

Scope

Choose what each evaluation runs against:

  • Trace — evaluate individual traces (one row per trace in the window).
  • Session — evaluate complete user sessions (one row per session).

Switching scope clears the metric, threshold, and unit — those aren't comparable across scopes.

Environments

Pick one or more environments. The rule only evaluates traces from these environments — so you can run the same rule against production only, without noise from staging or development.

The Environments field is hidden when you pick a score-based metric. Online-evaluation scores are not environment-scoped.

Condition

The condition step has two modes, selected by the Condition / SQL toggle:

  • Condition (default) — a guided builder you read as a sentence: Where Aggregation Metric Operator Threshold.
  • SQL — write the condition as a custom SQL query, for cases the guided builder can't express.

Using the guided Condition builder:

FieldOptions
AggregationAVG, MIN, MAX, P50, P95, P99, SUM. Score metrics also support COUNT.
MetricLatency (ms), Total Cost (USD), Prompt Tokens, Completion Tokens, Total Tokens, Error Count, plus any online-evaluation score in your project.
Operator>, <, >=, <=
ThresholdNumeric value. Unit auto-fills from the metric (e.g. ms for latency, USD for cost).

Example sentence: Where AVG Latency (ms) > 500.

Window and cooldown

  • Window — the look-back period. Options: 5 min, 10 min, 15 min, 30 min, 1 hour, 6 hours, 12 hours, 1 day, 3 days, 1 week. The alert is evaluated once per window interval.
  • Cooldown — after firing, the rule will not fire again for this duration. Options: 5 min, 15 min, 30 min, 1 hour, 6 hours. Prevents notification spam during a sustained breach.

Score-based alerts are capped at a 15 min window. If you change the window above 15 minutes while a score metric is selected, the metric resets and you'll need to pick a non-score metric.

Notification channel

Pick exactly one channel per rule:

  • Webhook URL (required) — must be http:// or https://. Private and link-local addresses (localhost, 127.0.0.0/8, 10.0.0.0/8, 192.168.0.0/16, 172.16-31.0.0/12, 169.254.0.0/16, IPv6 ULA fc00::/7, metadata.google.internal, hostnames ending in .local or .internal) are rejected.
  • Custom Headers — optional key/value pairs added to every webhook POST. Up to 10 headers per rule. Use this for Authorization tokens or routing keys.
  • Test Webhook — sends a sample payload to your URL using your configured headers, without creating a rule. Use this to verify connectivity and authentication before saving.
  • Email Recipients — comma-separated list of email addresses. Each address receives a copy of every firing notification for this rule.

Post alerts straight to a Slack channel, then pick the target channel from the dropdown.

Slack must be connected for your organization first — do that in Settings → Integrations, where an admin authorizes the BrowserStack Slack app. Once connected, the Slack channel option appears here and lists your workspace's channels.

Save

Click Create Alert. The rule is active immediately — the next scheduled evaluation will include it. You'll see a confirmation toast: "Alert created. Your alert rule is now active."

Create Alert modal with form filled in

Metrics reference

System metrics work on both Trace and Session scopes:

MetricUnitDescription
LatencymsEnd-to-end duration of the trace or session
Total CostUSDSum of generation costs
Prompt TokenstokensInput tokens consumed
Completion TokenstokensOutput tokens produced
Total TokenstokensSum of prompt + completion
Error CountcountNumber of failed observations

Score metrics appear as score:<score-name> and are populated from your Online Evaluations. Only scores produced by online evaluation (source = EVAL, environment = online_evaluation) are available — manual annotation scores and experiment scores do not feed alert rules.

Notification channels

Webhook payload

When an alert fires, the notification worker POSTs this JSON body to your webhook URL:

{
  "alertId": "cuid-of-the-rule",
  "alertName": "High latency on chat agent",
  "projectId": "your-project-id",
  "state": "FIRING",
  "message": "AVG latency exceeded 500 ms (actual: 742.31 ms) over the last 5 min",
  "condition": {
    "metric": "latency",
    "aggregation": "AVG",
    "operator": "GT",
    "threshold": 500,
    "scope": "TRACE",
    "windowMinutes": 5
  },
  "evaluation": {
    "metricValue": 742.31,
    "breached": true
  },
  "firedAt": "2026-05-11T14:00:00.000Z"
}

Delivery semantics:

  • Method: POST
  • Content-Type: application/json
  • Your Custom Headers are merged into the request headers (your Content-Type will be overridden if you set one).
  • Timeout: 10 seconds.
  • Retries: up to 3 attempts with exponential backoff (handled by the queue).
  • 4xx responses (except 429) are treated as permanent failures and skipped to the dead-letter queue immediately — fix your endpoint and resave the rule rather than waiting for a retry.

Email

Email recipients receive a formatted message containing the alert name, the breached condition, the actual metric value, and the time it fired. Email delivery uses the same retry policy as webhooks.

Slack

When an alert fires, a formatted message is posted to the Slack channel selected on the rule. Connect Slack once for your organization in Settings → Integrations (an admin authorizes the BrowserStack Slack app); after that, the Slack channel option lists your workspace's channels when you create or edit an alert.

Alert events

The Alert Events tab shows every event the engine has produced. Each event has a state:

StateMeaning
FIRINGCondition is currently breached. Initial state when an event is created.
ACKNOWLEDGEDA team member has acknowledged the event. The rule continues to evaluate; if it still breaches after the next window, a new event is created.
RESOLVEDMarked as no longer requiring attention. Typically you resolve once the underlying issue is fixed.

Alert Events tab showing fired events

Each event also records notificationResults — a per-channel delivery log: { channel, status, error? }. This is how you debug a notification that didn't arrive.

Permissions

Reading the Alerts page requires the alerts:read RBAC scope. Creating, editing, deleting rules, and acknowledging or resolving events use the corresponding write scopes on the same resource.

Limits

LimitValue
Notification channels per rule1 (webhook, email, or Slack)
Custom headers per webhook10
Webhook timeout10 seconds
Webhook retry attempts3 (exponential backoff)
Score-metric window cap15 minutes
Webhook URL — private/internal/link-localBlocked at save time

Use cases

  • Cost guardrailsAVG total_cost > 0.05 on a 1-hour window catches a runaway pipeline cheaper than discovering it in next month's bill.
  • Latency regression detectionP95 latency > 2000 ms on a 15-minute window over production only.
  • Hallucination spikeAVG score:faithfulness < 0.6 on a 15-minute window, paired with an online evaluation that scores faithfulness.
  • Error surgeSUM error_count > 10 on a 5-minute window — fastest signal that something is misconfigured downstream.