How do I correlate failed deploys with GitHub commits and pull requests using an AI SRE?

Tares puts GitHub commits and pull requests on the same per-service timeline as your deploys, metrics, logs and alerts, so an AI SRE sees what changed before a failure. You add one GitHub personal token source per repository and give it the same service label as your other sources. The agent then reads the order of events on one clock and can tie the failure to a specific commit or pull request.

How it works

Tares builds one timeline per service from every source that carries the same service label. Metrics, logs, alerts and deploy events all land there, and an agent reads the merged result with a single call. Most root causes are a change, so adding your commits and pull requests to that timeline lets the agent compare when the change landed with when the errors started.

For per-service correlation, use the GitHub connector with a personal token:

• You add one source per repository, so each source can carry its own service label.
• Each source polls its repository every 2 minutes by default. It reports commits, and pull requests opened, merged or closed.
• Each event carries labels such as repo, action, number, author, branch, sha, url and title. A closed pull request that merged reads merged.
• The first poll imports recent commits and no old pull requests.

Failed deploys come from a separate webhook source. Your CD pipeline posts one event per deploy, with a primary service label and event_type: deploy. Each post lands as a deploy event on that service’s timeline.

The GitHub App path works differently. It is one source for every repository the App is installed on, and it has no per-service service label. Its events carry the repo label instead, so use it for triggers that filter on repository, not for the per-service timeline.

Set it up

1. Create a fine-grained token on GitHub for the repositories you want, with Metadata read, Contents read and Pull requests read. Open Settings > GitHub, choose Add a personal token, and paste it.
2. Add a source per repository: Sources > Add source > GitHub, pick the credential and the repository, and save. Add a service label next to repo so the repository lands on the right service timeline. Use the same label name your metrics, logs and alerts sources use:

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

3. Create a webhook source for deploys (Sources > Add source > webhook). Give it a primary service label read from the payload’s service field, set event_type: deploy, and use a text template such as deploy {commit} by {author}: {message}. Creating it gives you a stable ingest URL.
4. Add one line to your CD pipeline that posts to that ingest URL on every deploy, with the service name, commit, author and message in the JSON body. A failed deploy shows up as a deploy event on the same service, next to the alerts and error logs it caused.
5. Open Explore, pick the service, and read the merged timeline. To let an agent investigate on demand, start the MCP endpoint in a second shell and connect your client:

tares mcp

6. Ask your agent: “Use tares: what happened to checkout in the last 15 minutes?” It answers from the correlated read, with commits, pull requests, deploys and errors in order.

For the full incident-response wiring, including triggers that wake an agent when an alert fires, follow Build an AI SRE.

What you get

• One timeline per service that shows a merged pull request, a deploy event and the first errors in the order they happened.
• Commits and pull requests with their author, branch, sha, title and link, so the agent can name the change that preceded the failure.
• A deploy event for every pipeline run, so a sequence such as “deploy landed 14:02, errors started 14:04” is visible to the agent without extra queries.
• Findings the agent writes back onto the same timeline, so the next investigation starts from the previous conclusion.
• Triggers that keep working across credential types. Both GitHub paths produce the same event shapes, so a trigger like a merged-pull-request filter on event_type and action survives a move from a token to the App.

When something else fits

• If you want events as they happen across every repository in one source, use the GitHub App. It also delivers pushes, reviews, releases and CI runs, but it has no service label, so those events do not join a per-service timeline. Use it with triggers that filter on repo.
• If you only need to know that a pull request merged, a trigger on the github source with event_type and action filters is enough, with no per-service timeline.

Related