How do I correlate high latency 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 latency metrics, logs and alerts, so an agent sees which change landed before latency rose. Connect GitHub with the GitHub App or a personal token, and keep every source keyed by the same service label. Then a trigger wakes an agent, or your MCP client reads the timeline on demand.

How it works

Tares builds one timeline per service. Every source that carries the same service label merges onto that timeline on one clock, so a latency alert, the p99 metric, the request logs and a merged pull request sit side by side. Most root causes are a change, so the order of events is what the agent needs: the change landed, then latency climbed.

The GitHub connector supplies the change side in one of two ways:

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

Both ways produce the same events and labels, so triggers keep working if you switch from a token to the App. Each event carries labels such as repo, action, author, branch, sha, title and url. Commits arrive as commit events with a token, and pushes arrive as push events with the App. A pull request that merged reads merged in action.

The latency side comes from the sources in the AI SRE guide: a Prometheus metrics source, a logs source, and an alerts source for rules such as HighLatency. Tares ingests what fires and does not re-threshold it. Your alerting stays where it is.

Set it up

1. Install and start Tares, then wire your latency sources as in the AI SRE guide: metrics, logs and alerts, all keyed by the same service label.

uv tool install tares          # or: brew install glassflow/tap/tares
tares up

2. 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.

3. For a self-hosted Tares, make it reachable by GitHub so webhooks 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

4. Or use a personal token. Create a fine-grained token with Metadata, Contents and Pull requests read access. In Settings > GitHub choose Add a personal token. Then go to Sources > Add source > GitHub and add a source per repository:

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

5. Make the GitHub events land on the service’s timeline. Give the GitHub source a service label whose value matches the service name on your metrics and logs. Without a shared label the events stay on their own timeline.

6. Add a trigger that wakes an agent on latency. You can react to the fired HighLatency alert, as the demo does, or threshold the typed field directly, for example max(p99_ms) > 1000. Subscribe a Tares agent whose prompt asks it to check recent commits and merged pull requests on the same service before it names a cause.

7. To investigate on demand, start the MCP endpoint and point your client at it:

tares mcp

Then ask: “Use tares: what happened to checkout in the last 15 minutes?” The client reads the correlated timeline, including the GitHub events.

8. Add deploys too. Create a webhook source with event_type: deploy and have your CD pipeline POST one line per deploy. A merged pull request shows what changed, and a deploy event shows when it reached production.

What you get

• One timeline per service with latency metrics, logs, alerts, commits, pull requests and deploys in time order.
• An agent that can say “pull request merged at 14:02, p99 rose at 14:04” and tie the finding to those evidence lines.
• A finding written back onto the service timeline, so the next investigation, yours or an agent’s, starts from the previous conclusion.
• Triggers on GitHub events, such as every merged pull request in chosen repositories, using filters on event_type, action and repo.
• With the GitHub App, agents that can also open pull requests and post a verdict as a check run, if you allow writes in the agent’s GitHub settings.

When something else fits

• If you only need to read commits from one repository and have no webhook access, the personal token path works, but it polls every 2 minutes and reports no pushes, reviews or CI runs.
• If latency has no code change behind it, such as a dependency outage or a config change, add a second webhook source with event_type: config so those changes reach the timeline too.

Related