How do I show GitHub commits and pull requests next to alerts from Prometheus for an AI SRE?

Tares shows GitHub commits and pull requests next to Prometheus alerts when both sources carry the same service label. Tares merges them into one timeline per service on a single clock, so the change reads first and the alert after. An AI SRE agent reads that timeline instead of querying each system.

How it works

• A prometheus_alerts source polls Prometheus’s own alerts every 30 seconds by default. Each alert becomes an event whose event_type is the alert name, with a state of firing, pending or resolved. A resolved event lands when the alert clears.
• A github source brings in commits and pull requests. With a personal token it polls every 2 minutes and reports commits and pull requests opened, merged or closed. With the GitHub App, events arrive by webhook as they happen, including pushes, reviews, issues, releases and CI runs.
• Tares builds one timeline per service from every source that carries the same service label. A commit at 14:02 and an alert at 14:04 sit on the same clock, so the cause comes before the symptom.
• That timeline is what a trigger hands to an agent, as in the Build an AI SRE guide.

Set it up

1. Add the alerts source. Use Sources > Add source > Prometheus alerts, enter the Prometheus url and choose Discover. The result looks like this:

- name: alerts
  connector: prometheus_alerts
  poll: 30s
  config:
    url: http://localhost:9090
    severities: critical,warning   # blank = all
    labels:
      - { name: severity, field: labels.severity, primary: true }
      - { name: state, field: state }

2. Promote the service label once alerts have arrived. Discover only proposes the labels every alert has, severity and state. An alert’s own labels, such as namespace or service, exist only while it fires. After a real alert has been ingested, open the source’s Fields tab and add the service label from there, so the field path comes from what your alerts actually carry. Details are on the Prometheus alerts page.

3. Create a GitHub credential. In Settings > GitHub, choose Add a personal token and paste a fine-grained token with Metadata, Contents and Pull requests read. The GitHub connector page also covers the GitHub App, which is the recommended path and delivers more event types.

4. Add one GitHub source per repository, with the same service name. With a token, each source follows one repository, so a constant service label marks which service that repository belongs to. Use the exact value your alerts carry:

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

5. Open the timeline. In Explore, pick the service. Commits, pull requests and alerts appear merged on one clock. Every GitHub event also carries labels such as repo, action, author, branch, sha and title, so the agent can tie an alert to a specific change.

6. Wake an agent on the alert. Add a trigger over the sources, keyed by service, that fires when an alert event arrives. Prometheus keeps owning the alerting, and Tares correlates what fired with the recent changes.

What you get

• One timeline per service with changes and alerts in time order, so a merged pull request followed by a firing alert is visible at a glance.
• Pull requests with their action (opened, merged, closed) and commits with their sha, author and title on the same service as the alert.
• A resolved event when the alert clears, so you see how long the incident ran after the change.
• An agent that reads the change and the alert together and can name the likely cause in its finding.
• Events with the same shape whether you use a token or the App, so a trigger keeps working if you switch later.

On a token source, the first poll imports recent commits and no old pull requests. A pull request reopened between two polls is not reported. Alerts are reported once per state change, not once per poll.

When something else fits

• If you want events as they happen instead of every 2 minutes, connect GitHub with the GitHub App. One source then covers every repository the App is installed on, and it adds pushes, reviews, releases and CI runs. Because that source spans repositories, check that the service value you need is present on its events before you rely on it.
• If your alerts reach you through Alertmanager rather than directly from Prometheus, the alertmanager connector takes them by webhook. The same service label approach applies.
• If your deploys do not map cleanly to a repository, send a deploy event from your CD pipeline through the webhook connector. The Build an AI SRE guide shows this with a deploy event carrying a service label.

Related