How do I find the change behind 5xx errors on an API in GitHub commits and pull requests?

Tares puts GitHub commits, pushes and pull requests on the same per-service timeline as your 5xx metrics, so the change behind the errors is the event just ahead of the first spike. Connect GitHub with the GitHub App or a personal token, give the source the same service label as your API, then read the timeline or ask your agent what changed before the errors began. Each pull request and commit event carries its author, branch, sha, title and link.

How it works

Tares correlates every source that carries the same service label onto one timeline, merged on one clock. When your metrics, logs and alerts for the API share a service label with your GitHub source, a commit or merged pull request sits in the same read as the 5xx rate.

What arrives depends on the credential you pick:

• GitHub App (recommended): events arrive as they happen, by webhook. You get push, pull_request, reviews, release and workflow_run events for every repository the App is installed on, in one source.
• Personal token: the source polls one repository every 2 minutes by default. You get commit events and pull_request events for opened, merged or closed. Each new commit carries its changed files in the payload (capped) while files is true, which is the default.

Both ways produce the same pull_request events, so a trigger or query keeps working if you switch later. Every event carries labels such as repo, action, author, branch, sha, url and title. A pull request that was closed after merging reads merged, and a push carries on_default_branch, which tells you whether it landed on the main line.

Set it up

1. Connect GitHub. 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. GitHub must be able to reach your Tares for webhooks to arrive, so a local tares up needs a tunnel and a public URL. For a token instead, create a fine-grained token with Metadata, Contents and Pull requests read, choose Add a personal token under Settings > GitHub, and paste it.
2. Add the source (token path). Add one source per repository under Sources > Add source > GitHub, or use this YAML. The App path creates its github source for you.

- name: checkout-api
  connector: github
  poll: 2m
  config:
    repo: acme/checkout-api
    credential: github
    labels:
      - { name: service, const: checkout-api, primary: true }
      - { name: repo, field: repo }

3. Key it to your API. Use the same service label value your metrics, logs and alerts use for the API. If a service spans several repositories, add a source or label for each one with that same value.
4. Start the read surface. Run tares up, then start the MCP endpoint in a second shell and connect your client:

tares mcp

5. Ask for the changes before the symptom. Ask: “Use tares: what changed on checkout-api before the 5xx errors started?” The agent reads the correlated timeline. Find the first 5xx or alert event, then look at the commit, push or merged pull request just ahead of it. Open the url label for the diff, and read author, title and sha to name who and what.
6. Optional: add deploys. If a deploy is a separate step from the merge, add a webhook source with event_type: deploy and call it from your pipeline, as the AI SRE guide shows. Then the timeline reads merge, deploy, errors.

A few details for reading results. The first token poll imports recent commits and no old pull requests. A pull request reopened between two polls is not reported. If the token cannot read pull requests, commits still arrive. If pull requests are missing, check that the token has Pull requests read. The full field list is on the GitHub connector page.

What you get

• One timeline where a commit, push or merged pull request sits next to the 5xx rate and the error logs for the same service.
• The author, branch, sha, title and link of each candidate change, plus the changed files for each commit on the token path.
• With the App, release and CI run events on the same timeline, so you can see whether a build or release finished just before the errors.
• An agent that starts from the timeline instead of querying each system, and whose finding is written back for the next investigation.
• Optionally, a trigger that fires on every merged pull request, for example in acme/checkout-api and acme/payments:

- 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 cause is not a code change, such as a dependency outage or a traffic spike, the GitHub events will show nothing useful just ahead of the symptom. Read the metrics, logs and alerts on the same timeline instead.
• If you deploy from a pipeline that is not tied to a merge, add a deploy event source so the timeline shows when the change went live, not only when it merged.
• If you want events as they happen rather than every 2 minutes, use the GitHub App instead of a token.

Related