How do I correlate a cron job that stopped with GitHub commits and pull requests using an AI SRE?

Tares puts the events from your cron job and from GitHub commits and pull requests on the same service timeline, so an agent reads the order of events from one source. You connect GitHub, give its events the same service label as the job’s events, and ask the agent what changed around the time the job stopped. Most root causes are a change, so the commit or merged pull request sits next to the job’s own events.

How it works

Tares builds one timeline per service from every source that carries the same service label, merged on one clock. The AI SRE guide describes this and recommends keeping all sources keyed by service.

Two kinds of events land on that timeline for your case:

• The cron job’s side. Send the job’s output or runs to Tares with whichever connector fits: docker_logs for a containerized job, OTLP for an OpenTelemetry pipeline, or a webhook source that the job posts to when it runs. If your existing alerting already notices that the job stopped, the alert reaches Tares through prometheus_alerts or alertmanager. Prometheus keeps owning the alerting, and Tares ingests what fired.
• The change side. The GitHub connector delivers commits and pull requests. With the GitHub App, pushes, pull requests, reviews, releases and CI runs arrive as they happen by webhook. With a personal token, Tares polls every 2 minutes for commits and for pull requests opened, merged or closed.

Every GitHub event carries labels such as repo, action, author, branch, sha, title and url. A closed pull request that merged reads merged. The agent can tie a specific sha or pull request number to the events around it.

Your agent then reads the correlated timeline, either woken by a trigger or asked by you over MCP.

Set it up

1. Start Tares and the MCP endpoint. Run tares up, then start the MCP endpoint in a second shell.

   tares up
   tares mcp

2. Connect GitHub. On Tares Cloud, choose Connect GitHub in your workspace settings. Self-hosted, open Settings > GitHub and choose Create GitHub App. A local Tares must be reachable from the internet for webhooks to arrive, so run a tunnel and set the public URL:

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

   With a personal token instead, add a source per repository. Name a service label so the events join the job’s timeline. The value is the service name your cron job’s events use, here billing as an example:

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

3. Send the cron job’s events with the same label. For a job that posts to a webhook source, read the service label from the payload:

   - name: cron-events
     connector: webhook
     config:
       labels:
         - { name: service, field: service, primary: true }

   Add one POST to the end of the job, using the ingest URL Tares gives you when you create the source. For a containerized job, use a docker_logs source with the same service label instead.

4. Connect your MCP client. For Claude Code:

   claude mcp add --transport http tares http://localhost:8788/mcp

5. Ask the question. For example: “Use tares: the billing cron job stopped, what changed on billing in the last 24 hours?” The client reads the correlated timeline and answers from the commits, pull requests and job events in order.

6. Optionally wake an agent automatically. Create a trigger over your alert source and the GitHub source, keyed by service. The agent that the trigger wakes reads the same timeline and writes its finding back onto it.

What you get

• Commits, merged pull requests, releases and CI runs on the same clock as the job’s own events, so the agent reads what landed and in what order.
• Labels on every GitHub event (sha, author, branch, title, url) that let the agent name the change instead of guessing.
• The same answer interactively over MCP and automatically through a trigger.
• A written finding on the service timeline, so the next investigation starts from the previous conclusion.
• Events that look the same whether they come from the App or a token, so triggers keep working if you switch.

When something else fits

• A personal token reports commits and pull requests opened, merged or closed, and polls every 2 minutes. Use the GitHub App when you also need pushes, reviews, releases or CI runs, delivered as they happen.
• If a change is not in GitHub, such as a deploy from another system, post it to a webhook source with the same service label so it joins the timeline too.

Related