How do I find the change behind a cron job that stopped in GitHub commits and pull requests?

Tares puts GitHub commits and pull requests on the same timeline as the cron job’s own events, so the change just ahead of the point where the job went quiet is easy to read. You ask for the last changes before the symptom began, then look at the commit, push or merged pull request closest before it. The github source works with a GitHub App or a personal token.

How it works

Tares keeps one timeline per key, such as a service, and merges every source that carries that key on one clock. The AI SRE guide builds this pattern: metrics, logs, alerts and deploys sit side by side, and an agent reads them as one correlated read.

The github connector adds code changes to that clock:

• With a personal token, Tares polls each repository every 2 minutes. Commits arrive as commit events and pull requests as pull_request events when they are opened, merged or closed.
• With the GitHub App, events arrive as they happen by webhook. Commits arrive as push events, and pull requests, reviews, releases and CI runs (workflow_run) arrive too.
• Both ways carry pull_request events, so a trigger on merged pull requests keeps working if you switch credentials.

Each event carries labels you can read when you trace a change: repo, action, author, branch, sha, url and title. A pull request that merged has the action merged. On a token source, each new commit also includes its changed files in the payload by default, so you can see whether the commit touched the schedule, the job code or its config.

When the cron job stops, its events stop. The last event it produced marks when the symptom began, and the GitHub event sitting just ahead of that point is your first suspect.

Set it up

1. Connect GitHub. 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, confirm it on GitHub, then choose Install on GitHub. For a personal token, choose Add a personal token in the same place and add a source per repository under Sources > Add source > GitHub.
2. For the App on a local Tares, make it reachable from GitHub, because webhooks need to reach your Tares:

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

3. Key the repository events to the same label as the cron job’s events, so they land on one timeline. For a token source, add a label next to the repository label. Replace checkout with the key your cron job’s source uses:

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

4. Start the MCP endpoint in a second shell and connect your client:

tares mcp

5. Ask for the change behind the symptom, for example: “Use tares: when did the nightly cron job for checkout last run, and what changed in the hours before that?”
6. Read the answer from the event just ahead of the last cron event. Check author, title, sha and url, and for a token commit the changed files. If the change was a pull request, check that its action is merged and look at its branch and base.

To be told about merges as they happen, add a trigger on the github source:

- 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

The full field list and permissions are on the GitHub connector page.

What you get

• One timeline where the cron job’s last event and the commit or merged pull request just before it sit on the same clock.
• A named suspect with an author, a title, a SHA and a link to open on GitHub.
• For token commits, the changed files, so you can tell a schedule or config edit from an unrelated change.
• With the App, CI run results (workflow_run) and releases on the same timeline, so a failed build or a release just ahead of the symptom shows up too.
• Findings your agent writes back to the timeline, so the next investigation starts from the last conclusion.

When something else fits

• If GitHub is not where the change happened, such as a config edit or a manual deploy, send those changes in through a webhook source with an event type of deploy or config, as the AI SRE guide shows.
• If the change landed more than a poll interval ago and you are using a token, remember pull requests reopened between two polls are not reported, and the first poll imports recent commits but no old pull requests.

Related