What are the steps between an alert firing and a diagnosis appearing on the service timeline?

Tares takes an alert from landing on the service timeline to a written diagnosis in four steps: source, trigger, agent and finding. Prometheus or Alertmanager keeps owning alerting, and Tares ingests what fired, correlates it with the evidence and wakes an agent. The agent writes what broke, since when, the likely cause and a next action onto the timeline, so an incident starts with a diagnosis instead of a blank page.

How it works

You connect your logs, metrics, alerts and deploys to Tares as sources, and Tares merges them into one timeline per service. Give every source the same service label, because that label is what puts them on one timeline. The AI monitoring guide covers the full picture. Between the alert firing and the diagnosis appearing, four steps run:

1. Source. The alert lands on the service’s timeline next to the metric that tripped it and the logs around it.
2. Trigger. A trigger watches the sources for that service and fires on a condition you choose. In the demo, it fires when an alert event arrives.
3. Agent. The trigger wakes a built-in Tares agent, or posts the timeline to your own agent service over a webhook. The agent starts with the correlated timeline already in front of it, so it does not spend its first minutes querying each system.
4. Finding. The agent writes what broke, since when, the likely cause tied to evidence lines and a next action onto the timeline. The next investigation, yours or another agent’s, starts from that finding.

Prometheus or Alertmanager stays in charge of deciding when an alert fires. Tares does not replace that. It takes in the alert, correlates it with the evidence and handles the waking.

The signals map to connectors like this:

• Metrics: Prometheus.
• Logs: Docker logs, OpenTelemetry (OTLP) or Vercel logs.
• Alerts: Prometheus alerts or Alertmanager.
• Deploys and changes: GitHub, or an inbound webhook from your CD pipeline.

Most real root causes are a change, so the deploy source is the one worth adding first.

Set it up

The demo runs the whole path on a laptop. It stands up a small api-server with Prometheus and a traffic generator, wires Tares to it, and lets you cause an incident on purpose.

1. Fetch the demo stack, start it, then install and start Tares. The stack gives Cause an incident something to break.

curl -O https://raw.githubusercontent.com/glassflow/tares/main/demo/docker-compose.yml
docker compose up -d
uv tool install tares          # or: brew install glassflow/tap/tares
tares up

2. Open the console at http://127.0.0.1:8787 and pick the AI SRE demo template under Projects.
3. Paste an Anthropic API key so the built-in agent can run, and click Start.
4. Optional: to read the same timeline from an MCP client such as Claude Code, start the MCP endpoint in a second shell.

tares mcp

Then point your client at it:

claude mcp add --transport http tares http://localhost:8788/mcp

5. Cause an incident with the Cause an incident button on the project page, or from a shell:

curl -s -XPOST localhost:8080/demo/inject -H 'content-type: application/json' \
  -d '{"scenario": "error_spike"}'

Within about 30 seconds the alert fires and the trigger wakes the agent. The finding lands on the timeline when the agent’s run finishes.

To run the same path on your real systems, follow Build an AI SRE. It walks through the demo step by step, connects an MCP client and then points the same setup at your own services.

What you get

• One timeline per service, with the alert next to the metric that tripped it and the logs around it.
• An agent that starts from the correlated timeline instead of querying each system first.
• A finding on the timeline that states what broke, since when, the likely cause tied to evidence lines and a next action.
• A starting point for the next investigation. Whether it is yours or another agent’s, it begins from the finding.
• The same timeline readable from Claude Code, Cursor and any other MCP client when you want to investigate yourself.
• Alerting that stays where it is, with Prometheus or Alertmanager still deciding what fires.

When something else fits

• If you want to investigate by hand, connect an MCP client such as Claude Code to the same timeline and read the evidence yourself.
• If you already run your own agent, have the trigger post the timeline to it over a webhook instead of waking the built-in Tares agent.
• If you need a tool to decide when alerts fire, keep that in Prometheus or Alertmanager. Tares works after the alert, not instead of it.

Related