How do I find the root cause of failed deploys with an AI SRE?

Tares puts metrics, logs, alerts and deploy events for each service on one timeline, so an agent can name the cause of a failed deploy, cite the evidence lines and write its finding back. You add your deploys as a webhook source keyed by the same service label as your other sources. A trigger wakes the agent when an alert fires, and the finding stays on the timeline for the next investigation.

How it works

Most real root causes are a change, so the deploy signal matters most. Tares does the data side and you bring the agent.

• One timeline per service. Every source that carries the same service label merges onto one clock. Metrics, request logs, fired alerts and deploy events sit side by side, so the agent sees “deploy landed 14:02, errors started 14:04” in a single read.
• Deploys as events. A webhook source receives one POST from your CD pipeline per deploy. Each POST lands as a deploy event on that service’s timeline, with the commit, the author and the message in the text.
• Prometheus keeps owning alerting. Tares ingests what fired, correlates it with the evidence and handles the waking. Nothing is re-thresholded.
• A trigger wakes the agent. A trigger such as incident watches the sources keyed by service and fires when an alert event arrives, per service. The woken agent reads the correlated timeline.
• The finding is written back. The agent records what broke, since when, the likely cause tied to specific evidence lines and a next action. The finding lands on the service’s timeline, so the next investigation starts from the previous conclusion instead of from scratch.

You can also pull. Connect an MCP client and ask what happened to a service in the last 15 minutes. The client reads the same correlated timeline and the finding.

Set it up

The Build an AI SRE guide walks through the full setup with a demo system. These are the steps that matter for failed deploys.

1. Install Tares and start it. You need Docker only if you use the demo system, and an Anthropic API key if you use the built-in agent.

uv tool install tares          # or: brew install glassflow/tap/tares
tares up

2. Open the console at http://127.0.0.1:8787. Create your metrics, logs and alerts sources with the Prometheus, Docker logs or OTLP, and Prometheus alerts or Alertmanager connectors. Give every source the same primary service label.
3. Add a webhook source for deploys under Sources, Add source, webhook. Make service the primary label, read from the payload’s service field, set event_type to deploy and use a text template that shows who shipped what. Creating the source 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 }

4. Add one line to your CD pipeline that POSTs JSON to the ingest URL on every deploy. The payload carries service, commit, author and message. A second webhook source with event_type set to config covers config changes the same way.
5. Create a trigger over your sources, keyed by service. Either react to fired alerts, as the demo’s incident trigger does with sum(alert_active) > 0 over 1m, or threshold the typed fields directly.
6. Choose who gets woken. A Tares agent needs only a prompt, so edit it to take the first look, tie the failure to evidence lines and suggest a next action. Your own agent service receives the timeline over a webhook. A Slack channel gets every firing and finding.
7. Optionally, start the MCP endpoint and point your client at it to investigate on demand.

tares mcp

What you get

• A deploy event beside the errors it may have caused, on the same clock, for each service.
• A diagnosis on the timeline before you have looked. Nothing is polled by hand and nobody is paged to start the investigation.
• Findings that cite specific evidence lines, so you can check the claim against the metrics, logs and alerts it rests on.
• A finding that persists. Each later investigation, by an agent or by you through an MCP client, reads the earlier conclusion first.
• Firings and runs you can follow in the console, including every run of the agent that handled them.
• Your existing alerting stays where it is. Tares ingests what fires and adds the correlation and the waking.

When something else fits

• If your deploys are not tied to a service label you can send in the payload, the agent cannot place them on the right timeline. Fix the label first.
• If you want one agent to query each system directly with its own tools, you can still connect it over MCP. The correlated timeline just gives it one read instead of many.

Related