How can an AI SRE see GitHub commits and pull requests just before Alertmanager alert groups?

Tares puts GitHub commits and pull requests and Alertmanager alerts on one per-service timeline, so an AI SRE reads the change and the first alert in order. Connect a github source and an alertmanager source, key both by the same label, and the agent sees the change land before the alert fires. The agent then writes the gap between them into its finding, where the next investigation finds it.

How it works

Each connector turns what it receives into events, and events that share an entity key sit on one timeline.

• Alertmanager is a push receiver. Alertmanager has already grouped and deduped, and Tares fans each batch out into one event per alert. The event type is the alert name, the text is its summary, and the labels include a status of firing or resolved. The full alert, including fingerprint, stays in the payload.
• GitHub arrives one of two ways. The GitHub App delivers pushes, pull requests, reviews, releases and CI runs by webhook as they happen. A personal token polls every 2 minutes and reports commits and pull requests opened, merged or closed. Both produce the same event types, so a trigger keeps working if you switch from one to the other.
• One key: the Alertmanager entity key comes from a label, in the order namespace, service, job, instance, or from a primary label you declare. Give the GitHub source a primary label with the same value and both land on one timeline for that service.

The agent reads that timeline with read. It sees a change event, such as a pull_request with action merged or a push, followed by an alert event with status firing. GitHub events carry labels such as repo, author, branch, sha, url and title, so the agent can name the exact change.

Set it up

1. Start Tares and the MCP endpoint your agent reads through.

tares up
tares mcp

2. Create the Alertmanager source under Sources, Add source, Alertmanager alerts. The source page shows a receiver block with the ingest URL filled in. Add it to alertmanager.yml and reload Alertmanager. See Alertmanager for every field.

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

3. When Tares has auth on, Alertmanager sends a Bearer Authorization header holding an ingest-scoped API key. You only need it in that case.

4. Check the receiver with a test batch, then look at Recent events.

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"}]}'

5. Connect GitHub. The App is recommended: on Tares Cloud choose Connect GitHub in workspace settings, and on a self-hosted Tares use Settings > GitHub and Create GitHub App. A local Tares needs a tunnel so GitHub can reach it. The GitHub page covers both paths.

cloudflared tunnel --url http://localhost:8787
TARES_PUBLIC_URL=https://<your-tunnel>.trycloudflare.com tares up

6. With a personal token, add one source per repository and give it the shared key as a primary label.

- name: checkout-api
  connector: github
  poll: 2m
  config:
    repo: acme/checkout-api
    credential: github
    labels:
      - { name: service, const: checkout, primary: true }

7. Make sure the Alertmanager alerts for that service resolve to the same key, using namespace, service or the key_label field. The AI SRE guide keys every source by one service label.

8. Tell the agent what to record. In its prompt, ask it to name the latest change before the first firing alert, give the change’s time and the alert’s time, and state the gap between them.

What you get

• One clock for change and symptom. In Explore and in the agent’s read, the merged pull request or push sits before the first firing alert for the same service.
• A named suspect. The agent can cite the change’s title, author, sha and url next to the alert name instead of saying something changed recently.
• A written gap. The agent writes a finding on the timeline with what broke, since when, the likely cause tied to evidence lines and a next action. Your prompt asks it to include the time between the change and the first alert. The next investigation, yours or an agent’s, starts from that finding.
• Prompt delivery with the App. Pushes and pull requests arrive as they happen, so the change is on the timeline before the alert fires. A token source polls every 2 minutes.
• Resolution in the same view. With send_resolved: true, the resolved event lands on the same timeline, so the agent can also write how long the incident lasted after the change.

When something else fits

• If you only need to react to merges, a trigger on the github source with event_type pull_request and action merged fires on each one, without a timeline read.
• If Prometheus alone owns your alerting and you do not need Alertmanager grouping or silencing, the prometheus_alerts connector polls fired alerts instead.
• If deploys matter more than commits, a webhook source called from your CD pipeline adds a deploy event to the same timeline, as the AI SRE guide shows.

Related