Can an AI agent read Alertmanager alert groups through Tares and explain them?

Yes, Tares lets an AI agent read the alerts Alertmanager routes to it and explain them from one correlated timeline. Each alert is stored as its own event with its labels, status and full payload. The agent connects only to Tares over MCP, so it needs no Alertmanager connector of its own.

How it works

Alertmanager has already evaluated, grouped and deduped your alerts. You point a webhook receiver at the ingest URL of an alertmanager source, and Alertmanager pushes each batch to Tares. With send_resolved on, you also see alerts move from firing to resolved.

Tares fans the alerts array of each batch out into one event per alert:

• event_type is the alert name.
• text is the alert summary.
• The alert’s labels become Tares labels, plus a synthetic status of firing or resolved.
• The full alert, including its fingerprint, stays in the payload. That keeps the annotations and the startsAt time from the batch with the event.

The entity key comes from a label automatically, in the order namespace, service, job, instance, or from a label you declare as primary. Because the key is a label, the alert lines up on one timeline with logs, metrics and findings from your other sources.

The agent never talks to Alertmanager. It talks to Tares through the MCP tools, such as read, catalog_list and catalog_describe. read returns a time-ordered timeline across all sources that match a label and value selector, so the alert comes back next to whatever else happened to the same entity. That is why the client needs no connector for the alert vendor: Alertmanager pushes to Tares, and the agent reads from Tares. See the Alertmanager connector for the full source reference.

Set it up

1. Create the source. Ask a connected agent: “Use tares to create an Alertmanager source and give me the webhook URL.” Or open Sources, choose Add source, pick Alertmanager alerts, name it and select Create. The source page shows a receiver block with the ingest URL filled in.

2. Add the receiver to your alertmanager.yml and reload Alertmanager:

receivers:
  - name: tares
    webhook_configs:
      - url: http://localhost:8787/ingest/<ingest_key>
        send_resolved: true
route:
  receiver: tares

3. If your Tares instance has auth on, the sender uses a Bearer Authorization header holding an ingest-scoped API key. Add it to the webhook_configs entry through Alertmanager’s http_config. An open local instance needs no credential.

4. Send a test alert and check Recent events in the console:

curl -X POST http://localhost:8787/ingest/<ingest_key> \
  -H 'Content-Type: application/json' \
  -d '{"alerts":[{"status":"firing","labels":{"alertname":"PostgresDown","severity":"critical","namespace":"prod"},"annotations":{"summary":"Postgres is down"},"startsAt":"2024-01-01T00:00:00Z"}]}'

The Fields view shows the alert labels, so you can promote namespace or service to correlate on.

5. If Tares runs on your machine, start the MCP server as a second process, because the daemon alone does not serve /mcp:

tares mcp --transport streamable-http --port 8788 --taresd http://localhost:8787

6. Connect your client to http://localhost:8788/mcp. Claude Code, Codex, Cursor and any MCP client work, and the connecting agents page has the exact snippet for each. On a server or Tares Cloud instance the MCP server is already running. On a secured instance, use an API key with the read scope.

7. Ask the agent: “Use tares: what alerts fired for prod in the last hour, and what else happened around them?” The client calls the read tools and answers from the correlated timeline.

What you get

• An agent that explains an alert from its own data: the alert name, summary, labels, status and the full payload with annotations and start time.
• Context beside each alert. Logs, metrics and findings for the same entity come back in the same read, so the explanation covers more than the alert text.
• Alertmanager’s own grouping, silencing and resolved handling, because Tares records what Alertmanager pushes.
• One connection to maintain. The client holds a single MCP connection to Tares and nothing for the alert vendor.
• The same read in the console. Reads lists each read as it happens, tagged client = mcp. The in-app Ask chat uses the same read tools.

For the wider picture of using Tares for incident work, see AI SRE.

When something else fits

• If you do not run Alertmanager and want Prometheus rules polled directly, the prometheus_alerts connector reads fired alerts on an interval. It does not carry Alertmanager’s grouping or silencing.
• If you only want a quick answer inside the console, use Ask and skip connecting an external client.
• If your agent should work inside one project only, give it a project key instead of a broad read key.

Related