How do I correlate crash loops with GitHub commits and pull requests using an AI SRE?

Tares puts GitHub commits, pushes and pull requests on the same per-service timeline as your crash-loop signals, so the agent sees the order of events. Connect GitHub, label the events with the same service label as your logs and alerts, and the agent reads one merged timeline. You can see whether a merge or commit landed before the restarts began.

How it works

Tares builds one timeline per service from every source that carries the same service label. Metrics, logs, alerts and GitHub events merge on one clock, and an agent works from that single read.

The GitHub connector adds the change side. It has two credential paths:

• GitHub App (recommended). Events arrive as they happen by webhook: pushes, pull requests, reviews, releases and CI runs (workflow_run). One source covers every repository the App is installed on.
• Personal token. Tares polls every 2 minutes by default and reports commits plus pull requests opened, merged or closed. You add one source per repository.

Both paths produce the same event shapes, so a trigger written for one keeps working on the other. GitHub events carry labels such as repo, action, author, branch, sha, title and conclusion. In the timeline, a line like “pull request merged by dana, branch main” sits next to the first crash-loop log line or alert, so the order is visible without switching tools.

A token source can lag by up to its poll interval, so for tight ordering the App is the better path.

Set it up

1. Connect GitHub. On Tares Cloud, choose Connect GitHub in your workspace settings, pick the organization and repositories, and confirm on GitHub. On a self-hosted Tares, open Settings > GitHub, choose Create GitHub App, confirm it on GitHub, then choose Install on GitHub and pick the repositories. For a personal token, choose Add a personal token in the same place, then add a source per repository under Sources > Add source > GitHub.

2. Make a local Tares reachable. GitHub must be able to reach Tares for App webhooks to arrive. A local tares up is not reachable from the internet, so run a tunnel and use its address as the public URL:

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

3. Put the repository on the service timeline. On a token source, add a service label with the same value your crash-loop sources use, and keep repo as a label too:

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

4. Label the crash-loop signal the same way. Whichever source carries the restarts, such as container logs, a metric or a fired alert, needs the same service label. The AI SRE guide walks through wiring metrics, logs and alerts keyed by service.

5. Optionally wake an agent on a change. A trigger on the github source can fire on every merged pull request. This one covers two repositories:

- name: pr-merged
  sources: [github]
  filters:
    - { field: event_type, op: eq, value: pull_request }
    - { field: action, op: eq, value: merged }
    - { field: repo, op: in, value: [acme/checkout-api, acme/payments] }
  condition: { aggregate: count, predicate: "> 0", window: 5m }
  cooldown: 5m

6. Investigate. Start the MCP endpoint and connect your client:

tares mcp

Then ask: “Use tares: what happened to checkout in the last 15 minutes?” The client answers from the correlated read, with commits, pull requests and crash-loop evidence in order.

What you get

• One timeline per service where a merged pull request, a push or a failed CI run appears next to the crash-loop evidence.
• An agent that can read the order of events, for example a merge, then the first restarts, then the alert.
• Commit and pull request detail on each event: sha, author, title, branch and url. On a token source, changed files are added to each commit’s payload by default.
• With the GitHub App, a verified delivery path. Every webhook is checked against the App’s secret before anything is stored, and a delivery GitHub sends twice is stored once.
• A finding the agent writes back to the timeline, so the next investigation starts from the previous conclusion.

When something else fits

• If the change that preceded the crash loop is a deploy or config push rather than a commit, add a webhook source for deploys and config changes. Your CD pipeline posts each deploy to it, and it lands on the same service timeline.
• If you only need a ping for each merged pull request and no correlation, the pr-merged trigger alone is enough.
• If a pull request is reopened between two polls on a token source, it is not reported. Use the GitHub App when you need every event.

Related