How do I correlate error spikes with GitHub App events using an AI SRE?

Tares puts GitHub App events on the same service timeline as your error metrics, logs and alerts, so an AI SRE sees whether a merge, push or CI run came before the spike. Connect the GitHub App, keep every source keyed by the same service label, and the agent reads one ordered timeline. A trigger on the alert wakes the agent, and it writes its conclusion back to that timeline.

How it works

• Events arrive as they happen. With the GitHub App, GitHub delivers pull requests, pushes, reviews, review comments, comments, issues, releases and CI runs by webhook. One github source carries every repository the App is installed on.
• Deliveries are checked. Tares verifies each delivery against the App’s webhook secret before storing it. A delivery GitHub sends twice is stored once.
• Events carry labels you can read. They include repo, action, branch, sha, title, author, conclusion for CI runs, and on_default_branch for pushes. A merged pull request reads merged.
• One timeline per service. Sources that share a label such as service merge onto one clock. Metrics, logs, alerts and GitHub events sit side by side in Explore, so a merged pull request at 14:02 and a HighErrorRate alert at 14:04 appear in that order.
• The agent works from that order. In the AI SRE setup, a trigger fires when an alert event arrives. A Tares agent wakes, reads the correlated timeline and writes a finding back. Most root causes are a change, so the finding can point at the pull request, push or CI run that landed first.

Set it up

1. Build the base from the AI SRE guide: a metrics source, a logs source and an alerts source, all keyed by the same service label, plus a trigger and an agent.
2. Connect the GitHub App. 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, continue on GitHub, then choose Install on GitHub and pick the repositories. Tares stores the App as a credential and creates the github source. You paste nothing by hand.
3. Make GitHub reachable if you run Tares locally. 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

4. Line up the keys. GitHub events carry repo, while your other sources carry service. Give the github source a primary label whose value matches the service name your other sources use. Labels can read a field and also support const, map, pattern and replace, so you can turn a repository name into a service name.
5. Optionally wake the agent on a change as well as on an alert. This trigger fires for every merged pull request in 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. Ask your connected MCP client what happened to the service in the last 15 minutes. It reads the correlated timeline, including the GitHub events and any earlier finding.

What you get

• Error alerts, error logs and the commit, pull request or CI run that preceded them on one clock, per service.
• An agent that starts from the order of events instead of querying each system separately.
• Findings written back to the timeline, so the next investigation starts from the previous conclusion.
• Triggers on GitHub events using labels such as action, repo and conclusion. The same triggers keep working if you later switch between a personal token and the App, because both produce the same event shapes.
• Optional write access for agents: with the App, a Tares agent can post its verdict on a pull request as a check run, and its writes show as the App.

When something else fits

• If you cannot install an App, a personal token polls commits and pull requests opened, merged or closed every 2 minutes. It has no CI run events and needs one source per repository. See GitHub.
• If your deploys do not go through GitHub, post each deploy from your CD pipeline to a webhook source with event_type: deploy and a service label. It lands on the same timeline.
• A self-hosted Tares that GitHub cannot reach receives no deliveries until you expose it with a tunnel or a public address.

Related