How do I find the change behind a cron job that stopped in GitHub App events?

Tares records GitHub App events such as pushes, merged pull requests, workflow runs and releases as they happen, each with a timestamp, author, sha and title. To find the change behind a stopped cron job, you note when the job last ran, then read the GitHub event that landed just before that moment. The GitHub connector page covers the events and labels, and AI SRE shows how Tares correlates evidence.

How it works

With the GitHub App connected, Tares receives GitHub webhooks and stores them in a github source that covers 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 you need for this question are:

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

Every event carries labels such as repo, author, branch, sha, url and title when they apply. That is enough to say what changed, who changed it and where to open it.

The cron job’s own evidence comes from whatever source you already run for it, such as its container logs or its metrics. If your pipeline also posts deploys to a webhook source with a service label, those deploy events sit on that service’s timeline next to its logs and metrics, so a deploy and the first missed run read on one clock.

Set it up

1. Connect the GitHub App. On Tares Cloud, choose Connect GitHub in your workspace settings, pick the organization and repositories, and confirm on GitHub. On a self-hosted Tares, open Settings > GitHub, choose Create GitHub App, then Install on GitHub and pick the repositories. 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. Find when the cron job went quiet. Look at the last event from its own source, such as its last log line or metric sample, and note the time. That is the start of the symptom.
3. Read the GitHub events just before that time. Open the github source and look at the events from the hours before the last good run. Start with push events on the default branch, then merged pull_request events, then workflow_run and release events.
4. Take the event closest ahead of the symptom. Read its title, author, branch and sha, and follow url to the commit or pull request. Check whether the change touched the job’s schedule, command or environment.
5. If a workflow_run sits there, read its conclusion. A failed deploy workflow just before the job stopped points at a deploy that never finished.
6. Optionally, have Tares watch for the next one. A trigger on the github source fires on the events you pick. This one fires on 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

Change the event_type value to push or workflow_run to watch those instead.

If you connected a personal token instead of the App, you get commits and pull requests opened, merged or closed, polled every 2 minutes. Pushes, workflow runs and releases arrive only with the App.

What you get

• A short list of the changes that landed before the cron job stopped, each with author, branch, sha and a link.
• One candidate change you can open on GitHub, the push, merged pull request or workflow run just ahead of the first missed run.
• A way to tell a code change (push, merged pull_request) from a release (release) or a CI outcome (workflow_run with its conclusion).
• Optionally, a trigger that fires on the next matching change, so you do not search by hand next time.
• Events from every repository the App is installed on, in one source.

When something else fits

• If the change was not a GitHub event, such as a config edit or a manual deploy, post it to a webhook source with a service label, so it lands on the service’s timeline with its logs.
• If you cannot reach Tares from GitHub, for example on a local tares up without a tunnel, no deliveries arrive. A personal token polls instead and gives you commits and pull requests.

Related