How do I show GitHub commits and pull requests next to Alertmanager alert groups for an AI SRE?

Tares shows GitHub changes and Alertmanager alerts on one timeline when both sources carry the same service label. Add an Alertmanager source and a GitHub source, key both on service, and an AI SRE reads the commit or merged pull request first and the alert after it. Both sources are connectors Tares already provides, so you only configure labels.

How it works

Tares builds one timeline per entity key. Events from different sources that share the key are merged on one clock, so a commit at 14:02 sits before an alert at 14:04 and the agent reads them in that order.

• Alerts. The Alertmanager connector is a push receiver. Alertmanager POSTs a batch of alerts to the source’s ingest URL, and Tares turns each alert into one event. event_type is the alert name, the text is the summary, and the alert labels become Tares labels plus a status of firing or resolved. The full alert, including its fingerprint, stays in the payload.
• Alert key. Tares derives the entity key from a label, in the order namespace, service, job, instance, or from a declared primary label. The advanced key_label field lets you pick the label yourself, so set it to service.
• Changes. The GitHub connector records commits and pull requests. With a personal token, each source polls one repository every 2 minutes and reports commits plus pull requests opened, merged or closed. With the GitHub App, events arrive by webhook as they happen and include pushes, reviews, releases and CI runs.
• Change key. Every GitHub event carries labels such as repo, action, author, branch, sha, title and url. A pull request is keyed owner/repo#number and a commit owner/repo. To merge them with alerts, declare a primary service label on the GitHub source so the change lands on the same entity as the alert.

The value of the service label must be identical on both sides. If Alertmanager alerts say checkout-api, the GitHub source must also say checkout-api.

Set it up

1. Start Tares with tares up, then open Sources > Add source > Alertmanager alerts, name the source and create it. The source page shows a ready alertmanager.yml receiver block with the ingest URL filled in.

2. Add that 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 Tares has auth on, the receiver sends a Bearer Authorization header holding an ingest-scoped API key. Without auth, you need nothing extra.

4. Key the alert source on service. If your alerts already carry a service label, Tares picks it up by default. Otherwise set key_label:

- name: alerts
  connector: alertmanager
  config:
    key_label: service

5. Add the GitHub source. Create a fine-grained token with Metadata, Contents and Pull requests read, add it under Settings > GitHub with Add a personal token, then use Sources > Add source > GitHub per repository. Declare a constant primary service label that matches your alerts:

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

6. Send a test alert and check Recent events and Fields:

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

7. Open Explore and pick your service. Commits, merged pull requests and alerts appear on one clock. Connect your agent over MCP, or let a trigger wake a Tares agent, as in Build an AI SRE.

With the GitHub App, one github source covers every repository it is installed on, and Tares creates it for you through the App flow. Use the token path when you want a per-repository service label as shown above.

What you get

• One timeline per service where the change comes first and the alert after, so the agent sees which commit or pull request landed before the failure.
• Alertmanager’s grouping, silencing and firing to resolved tracking stay as they are. Tares records what Alertmanager pushes and correlates it.
• Pull request events with action, author, branch, sha, title and url labels the agent can cite as evidence.
• The same events for both GitHub credentials, so triggers you write keep working if you later move from a token to the GitHub App.
• A trigger on merged pull requests, for example the pr-merged filter on event_type and action, if you also want a change alone to wake an agent.

When something else fits

• If you want Prometheus rules rather than Alertmanager’s grouping, use the prometheus_alerts connector for the alert side. The GitHub side stays the same.
• If your deploys are not visible in GitHub, send them from your CD pipeline through the webhook connector with a service label, as the AI SRE guide describes.

Related