How do I find the change behind error spikes in GitHub commits and pull requests?

Tares reads GitHub commits and pull requests into the same store as your error signals, so you can look at the last changes before an error spike began. Find the time the spike started, then read the commit, push or merged pull request that sits just ahead of it. Each GitHub event carries the repo, author, branch, sha and title, so you can name the change.

How it works

Tares connects to GitHub in one of two ways, and both produce the same events.

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

Every GitHub event carries labels when they apply: repo, action, number, author, branch, base, state, sha, url, title, conclusion, workflow, commits and on_default_branch. A closed pull request that merged reads merged. The event_type tells you what kind of change it was: commit (token), push (App), pull_request, release or workflow_run.

Your error signals, such as metrics, logs and alerts, are stored the same way. In the Build an AI SRE guide, sources that share a label such as service merge into one timeline per service. Error events and change events each carry a timestamp, so you can put them side by side and see which change landed just before the spike.

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. Self-hosted, open Settings > GitHub, choose Create GitHub App, confirm it on GitHub, then choose Install on GitHub and pick the repositories.
2. If you run Tares locally, make it reachable 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

3. If you prefer a personal token, create a fine-grained token with Metadata, Contents and Pull requests read. Choose Add a personal token under Settings > GitHub, then 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 }

4. Keep your error sources running next to it: metrics, logs and alerts, as described in Build an AI SRE. Deploy events from a webhook source work the same way, so a deploy marker can sit beside your commits.
5. Optionally, add a trigger so every merged pull request is recorded as its own firing. This one watches 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. When errors spike, note the time the spike began. Then read the GitHub events just before that moment. If you have an MCP client connected through tares mcp, ask it in plain words which commits, pushes or merged pull requests landed shortly before the errors started. Check action, author, branch and title on the last few events, and follow url or sha to the change itself.

What you get

• A short list of the last changes before the symptom: who made them, on which branch, and what they were titled.
• The commit sha or pull request number behind each change, with a link back to GitHub.
• With the App, pushes, merges, releases and CI runs in one place, so a failed workflow_run or a release shows up as part of the change history.
• With a token, each commit’s changed files are added to its payload by default, capped. That helps you see what a commit touched.
• Triggers that keep working if you later switch from a token to the App, because both produce the same events.
• A finding written back by an agent, so the next investigation starts from the previous conclusion.

When something else fits

• A token source reports less than the App. It sees commits and pull requests opened, merged or closed. It does not see reviews, CI runs, releases or pushes. A pull request reopened between two polls is not reported, and the first poll imports recent commits but no old pull requests. Use the GitHub App when you need those events.
• Local Tares and no tunnel. App deliveries cannot arrive until Tares is reachable. A token source polls and needs no inbound access.
• The change was a deploy or a config edit, not a commit. Your CD pipeline can post a deploy event to a webhook source, one POST per deploy, so the deploy time sits on the timeline. A second webhook source can do the same for config changes.
• No error signal yet. A GitHub source alone shows changes, not symptoms. Add metrics, logs or alerts first, following Build an AI SRE.
• Other GitHub details. Permissions, troubleshooting and agent settings are on the GitHub connector page.

Related