How do I find the change behind slow database queries in GitHub commits and pull requests?

Tares puts GitHub commits and pull requests on the same timeline as your slow-query signals, so you read the change that landed just before the symptom. Connect GitHub with the github connector, give it the same service label as your metrics and logs, then ask what changed before the slowdown began. The commit, push or merged pull request that sits just ahead of the first slow signal is your lead, with its sha, author, title and link.

How it works

Tares merges every source that carries the same service label into one timeline per service, on one clock. When your GitHub source carries that label too, the changes sit on the timeline next to the metrics, logs and alerts that show the slowdown. You read backwards from where the symptom starts and see the change just ahead of it.

GitHub events reach Tares in one of two ways, depending on the credential you pick:

• GitHub App (recommended). Events arrive as they happen by webhook: push, pull_request, reviews, releases and workflow_run. One source covers every repository the App is installed on.
• Personal token. Tares polls each repository every 2 minutes by default. You get commit events and pull_request events when a pull request is opened, merged or closed. Each new commit carries its changed files (capped) in its payload by default, so you can see whether a commit touched a query, a migration or a model.

Both ways produce the same events and labels. Each event carries repo, action, author, branch, sha, url and title where they apply. A closed pull request that merged reads merged. A push also carries on_default_branch, so you can tell a change on the default branch from one on a feature branch.

Set it up

1. Connect GitHub. On Tares Cloud, choose Connect GitHub in your workspace settings, pick the repositories and confirm on GitHub. On a self-hosted Tares, open Settings > GitHub, choose Create GitHub App and then Install on GitHub. For a token instead, choose Add a personal token and paste a fine-grained token with Metadata, Contents and Pull requests read.
2. On a local Tares, make it reachable so the App’s 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. With a token, add a source per repository under Sources > Add source > GitHub, or declare it as YAML. Add a service label with the same value your metrics and logs use, so the commits land on that service’s timeline:

- 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. Keep limit (commits fetched per poll, default 20) high enough to cover a busy repository, and leave files and prs at their defaults of true so each commit lists its changed files and pull requests are reported.
5. Start the MCP endpoint in a second shell and point your client at it, as in Build an AI SRE:

tares mcp

6. Ask for the changes ahead of the symptom:

Use tares: when did the slow queries on checkout start, and what commit or pull request landed just before?

Read the event sitting just ahead of the first slow signal. Its sha, title, author and url labels point you to the change, and the changed files tell you whether it touched the database path. The GitHub connector page lists every field and label.

What you get

• One timeline where a commit, push or merged pull request appears next to the slow-query signals, so you compare the time of the change with the time the symptom began.
• On each change event, the sha, author, title, branch and a link to GitHub, so you go from the timeline straight to the diff.
• On a token source, each commit’s changed files in the payload, so you can tell a query or schema change from an unrelated one.
• The same evidence for an agent. A trigger can wake a Tares agent, or your own, with the correlated timeline, and it reads the change events with the metrics and logs.
• Optionally, a trigger on merged pull requests. This one fires once per merged pull request in the repositories you list:

- 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

When something else fits

• If the slowdown follows a deploy or config change that never shows up as a commit, send those events to the timeline as well, for example from your CD pipeline.
• A token source reports commits on one branch and misses a pull request reopened between two polls. If you need pushes, reviews and CI runs as they happen, use the GitHub App.

Related