How do I correlate slow database queries 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 slow-query signal, so an AI SRE sees whether a change landed first. You give the GitHub source and your database sources the same service label. Then you ask your agent about the service, or let a trigger wake it. The agent reads one merged, time-ordered timeline instead of checking each tool in turn.

How it works

Most root causes are a change, so Tares keeps the change and the symptom on one clock.

• One timeline per service. Sources that carry the same service label merge into one timeline. Your slow-query signal can be a latency metric, query logs or a fired alert, and it lands there next to the GitHub events.
• GitHub events arrive in two ways. With the GitHub App, pull requests, pushes, reviews, releases and CI runs arrive by webhook as they happen. With a personal token, Tares polls every 2 minutes and reports commits plus pull requests opened, merged or closed.
• Commits carry their files. On the token path, each new commit’s changed files are added to its payload by default, so the agent can see whether a commit touched the query or the schema code.
• Labels you can read. GitHub events carry repo, action, number, author, branch, sha, title and more, so the agent can name the exact pull request or commit that preceded the slowdown.
• Pull or push. You can ask a connected MCP client what happened to a service, or a trigger can wake an agent when the slow-query alert fires. The agent writes its finding back onto the timeline, so the next investigation starts from that conclusion.

The AI SRE guide builds this whole loop end to end.

Set it up

1. Get your slow-query signal on a service timeline. Use the connector that fits what you have: prometheus for metrics, docker_logs or otlp for logs, prometheus_alerts or alertmanager for alerts. Give each source a service label.
2. Connect GitHub. The GitHub connector page covers both paths. On Tares Cloud, choose Connect GitHub in your workspace settings and pick the repositories. Self-hosted, open Settings > GitHub and choose Create GitHub App. A local tares up needs a tunnel so GitHub can reach it:

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

3. Or use a personal token. Add the token under Settings > GitHub, then add one source per repository. Because each source covers one repository, you can give it a constant service label so its commits and pull requests join 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. Check the timeline. Open Explore, pick the service and confirm that the commits, pull requests and slow-query events appear on one clock.
5. Ask or trigger. Start the MCP endpoint with tares mcp, connect your client and ask: “Use tares: what happened to checkout in the last 15 minutes?” To have an agent investigate on its own, add a trigger on your slow-query alert and subscribe a Tares agent to it.
6. Optional: add deploys. If the deploy matters more than the commit, add a webhook source with event_type: deploy and post to it from your CD pipeline. The guide shows the one-line call.

What you get

• A single timeline where a merged pull request, a push or a commit sits in order with the slow-query metrics, logs and alerts of the same service.
• An agent answer that names the change that landed before the slowdown, with the pull request number, author and branch from the event labels.
• Findings written back to the timeline, so a later investigation of the same service starts from the earlier conclusion.
• Triggers on GitHub events that keep working if you move from a personal token to the GitHub App, because both produce the same events.

Keep a few limits in mind. On the token path, the first poll imports recent commits and no old pull requests. A pull request reopened between two polls is not reported. Events can lag by up to the 2 minute poll interval. The GitHub App delivers as they happen.

When something else fits

• If your slowdowns follow deploys or config changes rather than commits, add a webhook source for them, as the AI SRE guide shows, alongside or instead of GitHub.
• If you want one source for every repository in an organization with events as they happen, choose the GitHub App. If you want a per-repository source with a fixed service label, the personal token fits better.
• If you only need to look at one slow query right now, a connected MCP client reading the service timeline is enough, with no trigger or agent to set up.

Related