What data does an AI SRE need to diagnose failed deploys?

Tares gives an AI SRE one correlated timeline per service, built from your deploy events, metrics, logs and alerts. Most real root causes are a change, so the deploy source is the one to add first. Give every source the same service label and the agent can line up when a deploy landed with when errors started.

How it works

Each signal is a source, and every source carries the same service label. That shared label puts them on one timeline per service, on one clock. The agent reads that timeline, whether a trigger woke a Tares agent, a trigger posted it to your own agent service over a webhook, or you are investigating through an MCP client.

For a failed deploy, each kind of source answers a different question:

• Deploy events say what changed and when. Use the webhook connector from your CD pipeline, or the GitHub connector for commits and pull requests.
• Metrics say what got worse. The Prometheus connector brings in values such as the 5xx rate, p99 latency and database connections.
• Logs say what the service reported. Use Docker logs, OpenTelemetry (OTLP) or Vercel logs.
• Alerts say what Prometheus rules or Alertmanager decided was wrong. Use the Prometheus alerts or Alertmanager connectors.

Prometheus or Alertmanager keeps owning alerting. Tares ingests what fired and correlates it with the evidence around it. When the agent finishes, it writes a finding onto the timeline: what broke, since when, the likely cause tied to evidence lines, and a next action. The next investigation starts from that finding. AI monitoring describes the full flow from alert to diagnosis.

Set it up

1. Add the deploy source first. Create a webhook source with a primary service label read from the payload, event_type: deploy and a text template. Creating it gives you a stable ingest URL.

- name: deploys
  connector: webhook
  config:
    event_type: deploy
    text_template: 'deploy {commit} by {author}: {message}'
    labels:
      - { name: service, field: service, primary: true }

2. Add one line to your CD pipeline that runs on every deploy.

curl -X POST https://<your-tares>/ingest/<ingest_key> \
  -H 'content-type: application/json' \
  -d '{"service": "checkout", "commit": "9f2c81d", "author": "dana", "message": "raise db pool size"}'

3. Add metrics with the Prometheus connector. Use your real PromQL and read service from the metric labels instead of a constant.
4. Add logs with the Docker logs connector for a container, or with OTLP for your OpenTelemetry pipeline.
5. Add alerts with the Prometheus alerts connector or the Alertmanager connector. Keep your alerting where it is.
6. Add a trigger over those sources, keyed by service. React to fired alerts, or threshold the typed fields directly, for example max(p99_ms) > 1000 for latency or an error-rate predicate for 5xx storms.
7. Choose who gets woken: a Tares agent with a prompt written for your stack, your own agent service over a webhook, or a Slack channel.

The Build an AI SRE guide walks through each of these steps against a demo system and then against your real systems. A second webhook source with event_type: config covers config changes the same way.

What you get

• Each deploy POST lands as a deploy event on that service’s timeline. The agent sees “deploy landed 14:02, errors started 14:04” in one read, without querying each system.
• Metrics, logs, alerts and deploys sit on one clock, so the agent can tie a failure to specific evidence lines.
• A trigger wakes the agent when your condition is met, so the diagnosis can be on the timeline before you open a dashboard.
• The finding stays on the timeline. An MCP client such as Claude Code reads the evidence and the finding together, so the next investigation starts from the previous conclusion.

If the agent cannot tell what happened, check what is missing from the timeline:

• No deploy source. The agent sees symptoms but not the change behind them. This is the gap to close first.
• Sources without the same service label. They do not land on one timeline, so the agent cannot line up a deploy with the errors that followed.
• No log source. The agent sees the metric move and the alert fire but has no request logs around the failure.
• No metric source. The agent sees the deploy and the logs but has no measure of how much worse the service got.
• No alert source. A trigger that fires on alert events has nothing to fire on. Threshold the typed fields directly instead.

When something else fits

• If you only want to investigate by hand, connect an MCP client to the same timeline and skip triggers and agents.
• If your deploys do not pass through a pipeline you can add a curl line to, the GitHub connector gives you commits and pull requests for a repo instead.

Related