How do I find the change behind slow database queries in GitHub App events?

Tares records GitHub App events such as pushes, merged pull requests, releases and CI runs as they happen, each with a time and labels like sha, branch and author. Find when the slow queries began, then read the GitHub events just before that moment. The last push, merge, release or workflow run ahead of the symptom is your first suspect. The GitHub connector page lists every event and label.

How it works

With the GitHub App, GitHub delivers events to your github source by webhook. One source covers every repository the App is installed on. Tares checks each delivery against the App’s webhook secret before it stores anything, and a delivery GitHub sends twice is stored once, so the event list stays clean.

The events that can explain a change in query behavior are these:

• push, with the labels sha, branch, commits and on_default_branch.
• pull_request, where action reads merged once a closed pull request has merged.
• release, with release_tag.
• workflow_run, with workflow and conclusion.

Every event also carries repo, author, title and url when they apply. The question to answer is simple: what was the last change before the symptom began? Take the time your slow-query metric or alert first moved, then read the push, pull_request, release and workflow_run events that sit just ahead of it.

The sha and url labels take you from the event to the exact commit or pull request, so you can check whether it touched a query, a migration, an index or a connection setting.

Set it up

1. Connect GitHub with the App. On Tares Cloud, open your workspace settings, choose Connect GitHub, pick the organization and repositories, and confirm on GitHub. Self-hosted, open Settings > GitHub, choose Create GitHub App, continue on GitHub, then choose Install on GitHub and pick the repositories.
2. If you run Tares locally, GitHub must be able to reach it. 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. Note when the slow queries began. Use the first point where your database latency metric rose or the first alert that fired.
4. Read the GitHub events from the minutes and hours just before that point. Look for a push with on_default_branch, a pull_request whose action is merged, a release, or a workflow_run and its conclusion. The repo label tells you which repository the change belongs to.
5. Or ask an agent to do the reading. Start the MCP endpoint, connect your client as the AI SRE guide shows, and ask for the last changes before the symptom:

tares mcp

Use tares: what were the last GitHub changes in acme/checkout-api before the database queries got slow?

6. To be told when a change lands, add a trigger on the github source. This example fires once per merged pull request:

- 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

In the console’s trigger editor, a filter on event_type or action over a GitHub source offers these values to pick from.

What you get

• A list of the changes that landed in your repositories, with the time each arrived, so you can see which one sits just ahead of the symptom.
• Labels that identify the change: sha, branch, author, title and url.
• The CI result for that change through workflow_run and its conclusion, so you can tell whether a failing or skipped run came before the slowdown.
• Pull request and release context, such as action, number and release_tag, to separate a code merge from a release.
• One source for every repository the App is installed on, so you search one place instead of one source per repository.

When something else fits

• If you want the change on the same per-service timeline as your metrics, logs and alerts, send deploys from your CD pipeline to a webhook source with a primary service label. The AI SRE guide shows the one-line curl for it.
• If you use a personal token instead of the App, you get commits and pull requests opened, merged or closed, polled every 2 minutes. Pushes, releases and CI runs need the App.
• If GitHub cannot reach your Tares, no deliveries arrive. Fix reachability first, as the connector page’s troubleshooting list describes.

Related