What does the JSON body a trigger POSTs to my agent contain, and how much timeline does it include?

Tares POSTs one JSON body with nine fields to each subscriber of a trigger, and its payload field carries the entity’s correlated timeline over the trigger’s context_window. You set that window under emit in the trigger. Your agent gets the context in the same request, with no follow-up call. This is part of how AI SRE wakes an agent with the relevant evidence.

How it works

When a trigger’s condition holds, Tares sends one POST with a JSON body to every subscriber. The body has these fields:

• dispatch_id: the id of this firing. Use it to dedupe, because delivery is at-least-once.
• trigger: the name of the trigger that fired, such as error_spike.
• project: the first of the running projects that use the trigger. If a project made the trigger, it is that one.
• projects: the list of all running projects that use the trigger.
• kind: the kind set under emit in the trigger.
• key: the entity the firing is about, such as the service name api-server. It comes from the trigger’s key_field, which defaults to the first source’s primary label.
• fired_at: the time of the firing, as an ISO 8601 timestamp.
• payload: the entity’s correlated timeline across the trigger’s sources, ready to hand to the model.
• run_ids: the Tares agent runs the same firing started. The list is empty when none started.

The payload covers the trigger’s sources over the context_window. For a trigger that watches metrics and logs, that means the deploy, the logs and the metrics around the spike, all for the one entity named in key. The trigger’s filters narrow which events count and which are handed over, so they shape the timeline too.

A trigger on a schedule, such as every: 10m, fires once per interval for all its events and hands over a summary of the window.

Set it up

1. Define the trigger with an emit block. The context_window value decides how much timeline lands in payload. Add the trigger on the project’s page, under Triggers, Add trigger, or in the catalog YAML:

triggers:
  - name: error_spike
    project: checkout watch   # optional; the Default project when left out
    sources: [checkout_metrics, checkout_logs]
    key_field: service        # optional; default: the first source's primary label
    filters:                  # optional; only these events count
      - { field: env, op: eq, value: prod }
    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
      context_window: 15m     # how much timeline to hand the agent
    cooldown: 5m              # minimum gap between firings for the same entity

2. Subscribe your agent. Over MCP, ask your agent to use the subscribe tool:

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

   The call subscribe(trigger, url) returns a subscription id. You can also register with POST /subscribe.

3. Run an endpoint that accepts a POST and starts your agent with the body as context. A small FastAPI or Express route, a serverless function or a workflow-engine webhook all work. Tares must be able to reach it.

4. Parse the body. It looks like this:

{
  "dispatch_id": "9f2c81d4…",
  "trigger": "error_spike",
  "project": "uc_1a2b3c",
  "projects": ["uc_1a2b3c"],
  "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…",
  "run_ids": ["run_4be1c0d2a9f3"]
}

5. Return a 2xx to acknowledge. Tares retries 5xx responses and transport errors with backoff. A 4xx is recorded as a failed delivery and is not retried. Dedupe on dispatch_id, since a firing can arrive more than once.

The full trigger syntax is in Watch with triggers.

What you get

• A single request that carries the whole story for one entity, so your agent starts with context and makes no follow-up call.
• A timeline whose length you control. With context_window: 15m, the payload covers 15 minutes across the trigger’s sources.
• A stable id, dispatch_id, for deduplication, and the run_ids that link the firing to any Tares agent runs it started.
• A record of every firing, even with zero subscribers. The console shows firings and per-subscriber delivery status under Firings, on the trigger’s own page and on the project’s Activity. Each dispatch has its own page with the delivery outcomes and the exact payload that was sent.
• The cooldown setting keeps a flapping condition from firing repeatedly for the same entity.

When something else fits

• If you want every trigger of a project delivered to one outside agent, join the project instead of subscribing trigger by trigger.
• If you want a Tares agent to act, wire it to the trigger in a project and turn it on there. The firing then lists its runs in run_ids.
• If you want a look at the sources on a clock rather than on a condition, give the trigger a schedule and you get a window summary.

Related