Watch with triggers

Have a view with a numeric field

Triggers aggregate a typed field, so the view must include a source that produces one. For example, a Prometheus source emitting rate_5xx, correlated into a service_timeline view keyed by service. See Connectors → prometheus and Concepts → views.

Define the trigger

A trigger names a view, a condition, what to emit, and a cooldown. Add it in the console (Triggers → New trigger) or in the catalog YAML:

triggers:
  - name: error_spike
    view: service_timeline
    condition:
      aggregate: max          # count | sum | avg | max | min | any
      field: rate_5xx
      predicate: "> 1.0"      # fire when max(rate_5xx) over the window exceeds 1.0
      window: 1m
      group_by: [key_value]   # evaluated per entity (per service)
    emit:
      kind: error_spike
      attach_view: true       # include the entity's timeline in the dispatch
      context_window: 15m     # how much timeline to attach
    cooldown: 5m              # minimum gap between firings for the same entity

The condition is checked as events are ingested. group_by: [key_value] evaluates it per entity, so each service fires independently.

Subscribe an agent

An agent registers a webhook over MCP with the subscribe tool:

Use tares to subscribe to the error_spike trigger and deliver to https://my-agent.example.com/hook.

subscribe(trigger, url) returns a subscription id. (You can also register via POST /subscribe.) The trigger’s page shows everything it delivers to, with per-subscriber delivery counts:

Receive dispatches

When the condition holds, Tares POSTs one JSON body to each subscriber:

{
  "dispatch_id": "9f2c81d4…",
  "trigger": "error_spike",
  "kind": "error_spike",
  "key": "api-server",
  "fired_at": "2026-07-17T09:14:03+00:00",
  "payload": "…the entity's correlated timeline, ready to hand to the model…"
}

With attach_view: true, payload is the entity’s correlated timeline over context_window: the deploy, the logs, the metrics around the spike, so the agent has context without making a follow-up call. Your endpoint can be anything that accepts a POST and starts your agent with the body as context: a small FastAPI/Express route, a serverless function, a workflow-engine webhook. It must be reachable from the Tares server.

Delivery rules:

• At-least-once. A firing can be delivered more than once; dedupe on dispatch_id.
• Acknowledge with a 2xx. 5xx responses and transport errors are retried with backoff; a 4xx is recorded as a failed delivery and not retried.
• Every firing is logged, even with zero subscribers. Firings and per-subscriber delivery status are in the console under Deliveries and on the trigger’s own page. Each dispatch has its own page with the delivery outcomes and the exact payload that was sent: