Alerting

Alerting checks a metric on a schedule and tells you when it crosses a threshold, and again when it recovers. Use it to catch a drop in success rate, a spike in negative sentiment, failing tools or transfers, rising latency or cost, without watching dashboards.

Open it from MONITOR > Alerting. A workspace can have up to 10 alert rules.

How a rule works#

1. Every rule has a Check frequency. A scheduler looks at the rules every 30 seconds and evaluates each one whose frequency has elapsed.
2. The metric is computed over the Time window ending now, for the selected agents.
3. If the condition is met and the rule was OK, it becomes Triggered: an alert_triggered notification is sent and a history event is recorded.
4. While it stays breached, nothing more is sent.
5. When the condition is no longer met, it goes back to OK and an alert_resolved notification is sent.

Create an alert#

Click Create alert.

A new alert starts as: Call success rate is below 80% over 1 hour, checked every 5 minutes.

Comparators#

Absolute value or change vs last cycle#

• Absolute value compares the metric in the window with the threshold. Rates are percentages (0 to 100) and costs are AUD.
• Change vs last cycle compares the window with the window just before it and uses the percentage change: (current - previous) / previous * 100. If the previous window was 0, the change is 0 when the current value is also 0, otherwise 100. Use a negative threshold with is below to catch drops, for example "is below -20" for a 20% fall. Concurrency used always uses its absolute value.

Metrics#

The dashboard offers these metrics:

These metrics are available through the API (GET /alerts/metrics lists them all):

Chat metrics ignore the agent filter. QA metrics apply it through the scored call's agent. See AI QA overview.

Notifications#

Email#

Each recipient gets a message with the subject [Tried] Alert triggered: <name> (or Alert resolved, Test alert) and the metric, value, threshold and window.

Webhook#

The rule's Webhook URL, or the workspace webhook when empty, receives a signed POST:

{
  "event": "alert_triggered",
  "alert": {
    "alert_id": "alert_5c1d...",
    "name": "Success rate drop",
    "metric": "call_success_rate",
    "threshold_type": "absolute",
    "comparator": "<",
    "threshold": 80,
    "window_minutes": 60,
    "frequency_minutes": 5,
    "agent_ids": [],
    "emails": ["ops@example.com"],
    "webhook_url": "https://example.com/hooks/alerts",
    "enabled": true,
    "state": "triggered",
    "last_value": 72.5,
    "last_checked_timestamp": 1760850000000,
    "created_timestamp": 1760000000000,
    "value": 72.5,
    "message": "Success rate drop: call_success_rate is 72.5% (< 80%) over the last 60 min",
    "timestamp": 1760850000000
  }
}

event is alert_triggered, alert_resolved or alert_test. Deliveries carry the same signature headers as call webhooks (x-tried-signature and x-retell-signature).

The alert list#

Each row shows the name, the condition in words with the check frequency, the agents, where notifications go (Workspace webhook when neither email nor webhook is set), the last value and when it was checked, an enable switch and the status: OK, Triggered or Paused.

Row actions:

• Check evaluates the rule now and applies the transition, the same as the scheduler. A toast says Triggered, Resolved, Still breached or Within threshold.
• Test sends an alert_test notification to the emails and webhook without changing the state, and records a Test event.
• The pencil edits the rule; the trash icon deletes it with its history.

History#

The History tab lists triggers, resolutions and tests, newest first, for All alerts or one rule.

API#

Rule fields: name, metric, threshold_type (absolute or relative, default absolute), comparator (default >), threshold, window_minutes (1 to 10080, default 60), frequency_minutes (1 to 1440, default 5), agent_ids, emails, webhook_url, enabled (default true). The API accepts any window and frequency in range, not only the dashboard presets.

Related#