How do I find the change behind crash loops in GitHub App events?

Tares stores GitHub App events as they happen, so you can find the change behind crash loops by reading the push, merged pull request, release or CI run events just before the symptom began. Each event carries labels such as repo, sha, action, author and branch, so you can name the exact commit. Take the time the crash loops started from your alert or log evidence, then work backward through the repository’s events.

How it works

The GitHub App delivers events by webhook as they happen. A github source carries every event of the repositories the App is installed on, in one source. Every delivery is checked against the App’s webhook secret before it is stored, and a delivery GitHub sends twice is stored once, so the history you read back has no duplicates.

The events that can explain a crash loop are these:

• push, keyed by owner/repo, with the labels sha, branch, commits and on_default_branch.
• pull_request, keyed by owner/repo#number, where a closed pull request that merged has the action merged.
• release, with the label release_tag.
• workflow_run, with the labels workflow and conclusion.

The labels repo, author, title, url and sha tell you who changed what and where to open it on GitHub.

The method is to work backward from the first sign of trouble:

1. Find when the symptom began. Use the first alert or the first error log line for the crashing service.
2. List the GitHub events for the affected repository in the window just before that moment.
3. Read the last push, merged pull request, release or successful CI run ahead of it. That is your candidate change.
4. Open its url, check the sha and the changed files, and compare them with what the crash loop is complaining about.

A gap matters. A change that landed hours before the first crash is a weaker suspect than one that landed minutes before it.

Set it up

1. Connect GitHub with the App, because only the App delivers pushes, releases and CI runs. 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, make it reachable from GitHub so webhooks arrive. 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. Check that deliveries are arriving. GitHub’s App settings list recent deliveries under Advanced, with their responses.
4. Keep your symptom evidence in Tares too: metrics, logs and alerts, each from its own source. Build an AI SRE shows how sources keyed by the same service label merge into one timeline per service on a single clock.
5. Optionally, mark merges as they land with a trigger on the github source. This one 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. If you want deploys on the service’s own timeline, add a webhook source with a primary service label and event_type: deploy. Post one event from your CD pipeline on every deploy. Each POST lands as a deploy event on that service’s timeline, so the agent sees a deploy followed by the first errors.

The full list of permissions, events and fields is on the GitHub connector page.

What you get

• A dated record of pushes, merged pull requests, releases and CI runs for every repository the App is installed on, in one source.
• A candidate change for the crash loops: the last event before the symptom, with its sha, author, title, branch and url.
• A way to tell a risky change from a harmless one. A failed workflow_run with a conclusion label just before the symptom reads differently from a green one.
• Triggers that keep working if you later switch from a personal token to the App, because both produce the same events.
• With a deploy webhook in place, a deploy event on the service’s timeline right next to the crash-loop evidence.

When something else fits

• If you only need commits and pull requests opened, merged or closed, a personal token works. It polls every 2 minutes and does not deliver pushes, releases or CI runs, so it is a weaker fit for this question.
• If the cause is a config change or a deploy that never touches GitHub, send it through a webhook source from your pipeline instead.

Related