How do I find the change behind failed deploys in GitHub App events?

Tares records GitHub App events as they happen, so you can find the change behind a failed deploy by reading the push, merged pull request or CI run just before it. Ask for the last changes before the failure began, then check the sha, branch and repo labels on the events nearest the failure. Each event carries its time and labels, so the commit that came first is easy to pick out.

How it works

With the GitHub App connected, Tares receives GitHub webhooks as they happen and stores them in one github source covering every repository the App is installed on. Each delivery is checked against the App’s webhook secret, and a delivery GitHub sends twice is stored once.

The events that matter for a failed deploy are:

• workflow_run: a CI or deploy run. The conclusion label holds its result, and workflow, branch and sha tell you which run and which commit.
• push: a push to a branch. It carries sha, commits and on_default_branch.
• pull_request: with the action label set to merged, it shows what landed on the base branch.
• release: a published release, with release_tag.

Because every event has a time and the same label names, the change behind a failure is the event that sits just ahead of it. You find the failed run, take its sha and repo, and read backwards to the push or merge for that commit. If your AI SRE setup is already wired, an agent connected over MCP can read the same evidence for you.

Set it up

1. Connect the GitHub 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. GitHub must be able to reach your Tares, so a local tares up needs a tunnel:

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

2. Check that workflow_run, push and pull_request events arrive for the repositories you deploy from. The GitHub connector page lists every event type and label.
3. Find the failed deploy. Look at workflow_run events for your deploy workflow, read the conclusion label, and note the run’s repo, branch and sha.
4. Read the events just ahead of it. Look for a push on the same repo and branch, or a pull_request with action set to merged, in the minutes before the run. The one whose sha matches the failed run is the change. If several landed close together, the author, title and url labels tell you which one to open.
5. Ask an agent to do the same read. Start the MCP endpoint in a second shell:

tares mcp

Then ask your connected client something like: “Use tares: what changed in acme/checkout-api before the last failed deploy?” It reads the evidence and answers from the events around the failure.

6. Optional: get woken when a CI run arrives. A trigger on the github source can filter on event_type, using the same filter shape as the merged pull request example on the connector page:

- name: ci-run
  sources: [github]
  filters:
    - { field: event_type, op: eq, value: workflow_run }
  condition: { aggregate: count, predicate: "> 0", window: 5m }
  cooldown: 5m

If your deploys do not run as GitHub workflows, send each deploy from your pipeline to a webhook source with event_type set to deploy, as the AI SRE guide shows. Those deploy events then give you the change to compare against the GitHub events for the same commit.

What you get

• The commit, push or merged pull request that came just before a failed deploy, with its author, title, sha and url.
• The failed workflow_run and its conclusion next to that change, so you see cause and effect in order.
• The same events in a repeatable form: a filter, a trigger or an agent question you can run on the next failure.
• Events from every repository the App is installed on in one github source, so a failure in one service does not send you looking across many sources.

When something else fits

• If you connect with a personal token instead of the App, you get polled commit events and pull requests opened, merged or closed, but no push or workflow_run events, so you cannot read CI results.
• If the deploy runs outside GitHub Actions, send it from your pipeline to a webhook source so the deploy itself is an event.
• If you want the full walkthrough of correlating changes with metrics, logs and alerts, follow the AI SRE guide.

Related