Analytics Alerts

Schedule an existing Analytics API and open Incidents from governed numeric thresholds.

Last verified 2026-08-30

An Analytics Alert reuses an existing Analytics API as its query primitive. It does not introduce another aggregation engine or duplicate the Analytics definition.

Choose an Analytics API, a numeric output alias, one operator (gt, gte, lt, lte, or equals), and a comparison value. The evaluation interval is 60 to 86,400 seconds. consecutive_evaluations can require 1 to 20 consecutive matches before opening or merging an Incident.

{
  "project_id": "PROJECT_ID",
  "name": "Sustained high average latency",
  "enabled": true,
  "severity": "warning",
  "trigger_type": "analytics",
  "analytics_id": "LATENCY_ANALYTICS_ID",
  "trigger_mode": "analytics_threshold",
  "analytics_field": "average_latency_ms",
  "analytics_operator": "gt",
  "analytics_value": 400,
  "evaluation_interval_seconds": 300,
  "consecutive_evaluations": 2,
  "cooldown_seconds": 900,
  "channel_ids": ["ON_CALL_CHANNEL_ID"],
  "conditions": { "combinator": "and", "conditions": [] }
}

The scheduler claims due rules through the database so multiple Core instances do not intentionally run the same schedule slot. Each query has a timeout. Query, binding, or conversion failure increments the failure metric and schedules the next evaluation without creating a false-positive Incident.

The first qualifying evaluation queues notification immediately. cooldown_seconds must be at least 300 and controls only later summary notifications for the same active Incident; it does not delay detection. Pending delivery coalescing and project/channel rate limits are shared with Event Alerts.

Current-period versus previous-period percentage comparison is not exposed by the Alert contract. Model that comparison in an Analytics API first, then alert on its numeric output.

Was this page helpful?Send feedback