Skip to content

Alerting

Alerting (Pro) notifies your team when run behavior crosses defined conditions.

The alerting system has three parts:

  • destinations: where notifications are sent
  • rules: what conditions trigger alerts
  • events: historical delivery and trigger log

Three delivery channels are available:

  • Webhook: generic HTTP callback
  • Email: one or more addresses
  • Slack: posts to a Slack channel via incoming webhook

Seven trigger types are available:

TriggerDescription
run_failedConsecutive run failures exceed threshold
latency_regressionLatency percentile exceeds threshold
suite_disabledA suite is auto-disabled
endpoint_disabledAn endpoint is auto-disabled
low_faucetFaucet wallet balance is low
api_key_expiryAPI key is nearing expiration
http_status_spikeHTTP status code spike detected (e.g. 429, 5xx)

Rules can be scoped to:

  • tenant-wide
  • specific chain
  • specific suite

This lets you combine broad safety nets with high-signal critical-suite rules.

Rules support cooldown windows to prevent alert floods.

Rules can send recovery signals when condition clears.

Use recovery notifications to close incident loops automatically.

  • page only on sustained failures, not single transient errors
  • keep cooldown longer than expected retry turbulence
  • route low-priority drift (warn) to async channels
  • review alert events weekly and tune rules
  • Slack: concise summary, run link, suite name, chain name
  • Webhook: include structured fields for downstream routing
  • Email: include human-readable summary for on-call handoff
  1. warn verdict drift -> Slack channel only
  2. repeated suite failure in 10m -> urgent webhook or email
  3. recovery signal -> close incident thread automatically
  • deduplicate on suite and condition key
  • require a minimum count in a time window
  • disable low-value rules during maintenance windows