What trigger condition catches failed deploys early?

Tares catches failed deploys early with a trigger that sums a numeric failure field over a short window, per service, with a predicate such as ”> 0” and a cooldown. The condition is checked as events arrive, so it fires on the first failed deploy in the window instead of waiting for an error spike. When it fires, Tares sends the service’s correlated timeline to your subscribed agent.

How it works

A trigger watches one or more sources and evaluates its condition as each event is ingested. For failed deploys, four parts of the condition do the work:

• aggregate and field. The aggregate is one of count, sum, avg, max, min or any. It runs over a typed field, so at least one source must produce a numeric field. For deploys, that is a field that is 1 when a deploy failed and 0 when it succeeded, or a count of failed steps.
• window. The span the aggregate covers, for example 10m. A short window makes the trigger react quickly. A longer one smooths out noise.
• predicate. The test applied to the aggregate, such as ”> 0”. With a sum over a 0 or 1 field, this fires on the first failed deploy in the window. Use ”> 1” if you want two failures before it fires.
• group_by: [key_value]. Evaluates the condition per entity, so each service fires on its own. key_field names that entity, such as service, and each source should carry it.

cooldown sets the minimum gap between firings for the same entity, so a service that keeps failing does not wake your agent on every retry. filters narrow which events count, for example only env equal to prod.

This is the same shape as the other incident triggers in the Watch with triggers guide, which pairs max(rate_5xx) > 1.0 with an error storm and max(p99_ms) > 1000 with latency. For failed deploys you pick the aggregate and field that match that symptom. It is one of the watching patterns in the AI SRE guide.

Set it up

1. Make sure a source carries a numeric deploy field. Add a label with type: number for the failure signal and a primary label for the entity. This webhook source example reads both from the posted JSON:

- name: ci_events
  connector: webhook
  config:
    labels:
      - { name: service, field: service, primary: true }
      - { name: deploy_failed, field: deploy_failed, type: number }

2. Define the trigger. Add it on the project’s page (+ next to Triggers), under Triggers → Add trigger, or in the catalog YAML:

triggers:
  - name: failed_deploys
    sources: [ci_events]
    key_field: service
    filters:
      - { field: env, op: eq, value: prod }
    condition:
      aggregate: sum
      field: deploy_failed
      predicate: "> 0"
      window: 10m
      group_by: [key_value]
    emit:
      kind: failed_deploy
      context_window: 15m
    cooldown: 10m

3. Choose the window and predicate for your risk. A window of 10m with ”> 0” reacts to the first failure. Raise the predicate or widen the window if single failures are routine in your pipeline.

4. Set the context. context_window is how much timeline Tares hands the agent. Set it wide enough to include the deploy and the logs and metrics around it.

5. Subscribe an agent. A Tares agent is woken by the trigger once you turn it on in the project. An external agent registers a webhook over MCP with the subscribe tool, for example: Use tares to subscribe to the failed_deploys trigger and deliver to your agent’s URL. Your endpoint must be reachable from the Tares server.

6. Acknowledge deliveries. Return a 2xx. Tares retries 5xx responses and transport errors with backoff and does not retry a 4xx. Delivery is at-least-once, so dedupe on dispatch_id.

What you get

• A per-service signal. Each service is evaluated on its own, so one broken deploy does not hide behind healthy ones.
• An early, bounded alert. The first failure in the window can fire the trigger, and the cooldown keeps repeated failures for the same service from firing repeatedly.
• Context in the dispatch. The JSON body carries trigger, kind, key (the service), fired_at and a payload with the entity’s correlated timeline across the trigger’s sources over context_window: the deploy, the logs and the metrics around it. Your agent starts with that context and needs no follow-up call.
• A record of every firing. Firings and per-subscriber delivery status appear in the console under Firings, on the trigger’s page and on the project’s Activity, even when nobody is subscribed.

When something else fits

• If you want to review deploys on a clock instead of reacting to a condition, give the trigger a schedule with condition: {every: 10m}. It fires once per interval and hands over a summary of the window.
• If you want to watch first and escalate only when something looks wrong, see Watch, then escalate for the follow-on pattern.

Related