How do I find the change behind high latency in GitHub commits and pull requests?

Tares puts GitHub commits and pull requests on the same timeline as your latency signals, so you read the change just ahead of the symptom. Connect GitHub, label the source with the same service label as your metrics, and ask for the last changes before latency began. Each event carries its author, title, sha and url, so you can open the change in GitHub.

How it works

Tares has a github connector. It turns repository activity into events with the same labels whichever credential you use.

• With the GitHub App, events arrive as they happen by webhook: pull requests, pushes, reviews, issues, releases and CI runs.
• With a personal token, Tares polls every 2 minutes by default and reports commits, plus pull requests opened, merged or closed.
• Every event carries labels when they apply: repo, action, number, author, branch, sha, url and title. A pull request that was closed after merging reads merged.
• With a token source, files is true by default, so each new commit’s changed files are added to its payload, capped.

Tares builds one timeline per service when your sources carry the same service label. Metrics, logs, alerts and change events then sit on one clock, as the Build an AI SRE guide describes. You find the change by reading that timeline. Look at where the latency metric or the HighLatency alert starts, then read the commit, push or merged pull request event just ahead of it.

Set it up

1. Connect GitHub. On Tares Cloud, choose Connect GitHub in your workspace settings. On a self-hosted Tares, open Settings > GitHub and choose Create GitHub App. For a personal token, choose Add a personal token in the same place and paste it. The GitHub connector page has the permissions and the steps for each path.
2. If you use a token, add one source per repository with Sources > Add source > GitHub, or declare it like this:

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

3. Give the GitHub source the same service label that your latency source uses, so its events land on that service’s timeline in Explore. With the App, GitHub must be able to reach your Tares. A local Tares needs a tunnel:

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

4. Start the MCP endpoint and connect your client:

tares mcp

5. Ask for the changes before the symptom, for example: “Use tares: what happened to checkout in the last 60 minutes, and what changed just before latency rose?” Read the commit, push or merged pull request events that sit ahead of the rise. Open the url label to see the change in GitHub.
6. To be woken when a pull request merges, add a trigger on the github source. The pull request merged example on the connector page filters on event_type pull_request and action merged.

What you get

• One timeline where the latency rise and the GitHub changes before it are side by side, with the time of each.
• For every change, the author, title, sha, branch and url labels, so you know who to ask and where to look.
• For commits from a token source, the changed files in the payload, so you can see what the commit touched.
• The same event types and labels on both credential paths. A trigger written for a token keeps working when you move to the App.
• Your agent starts from the same read you do, and its finding is written back to the timeline for the next investigation.

When something else fits

• A merged pull request is not always the moment code reached production. If you need the deploy time itself, add a webhook source that your pipeline posts to on every deploy, as the Build an AI SRE guide shows.
• A token source polls, so a change can show up up to a poll interval after it happened, and a pull request reopened between two polls is not reported. Use the GitHub App when you want events as they happen, including pushes.

Related