How do I find the change behind a disk filling up in GitHub commits and pull requests?

Tares puts GitHub commits and pull requests on the same timeline as your disk metric or alert, so the change behind a disk filling up is the event just ahead of the first symptom. You connect GitHub, give the source the same service label as your other sources, and ask your agent for the last changes before the symptom began. The agent reads one merged timeline and names the commit, push or pull request that sits just before it.

How it works

Tares merges every source that carries the same service label into one timeline on one clock. Add GitHub to that set and a commit or a merged pull request shows up between the metric and alert events, in order.

The GitHub connector brings these events, depending on the credential you pick:

• GitHub App: push, pull_request, pull_request_review, release and workflow_run, delivered by webhook as they happen.
• Personal token: commit and pull_request (opened, merged or closed), polled every 2 minutes by default.

Each event carries labels that help you pin down the change: repo, action, author, branch, sha, title and url. With a personal token, files is on by default, so each new commit’s changed files (capped) are added to its payload. When the disk grew because of a changed config, a new log path or a new job, the file list is where you see it.

The symptom arrives from whichever source you already run, such as a Prometheus metric or a fired alert. Deploys can arrive from a webhook source with event_type: deploy. The timeline then reads like this: a deploy or merge, a few minutes later the first disk event.

Set it up

1. Connect GitHub. The GitHub App is the recommended path. On Tares Cloud, choose Connect GitHub in your workspace settings. Self-hosted, open Settings > GitHub and choose Create GitHub App. A local tares up needs a public address for webhooks, so run a tunnel first:

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

   For a personal token, open Settings > GitHub, choose Add a personal token and paste a fine-grained token with Metadata, Contents and Pull requests read access.

2. Add the source for the affected repository. For a token, use Sources > Add source > GitHub, or this YAML. The service label is what puts the commits on the same timeline as your disk metric:

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

3. Check the symptom source uses the same label. Your disk metric or alert source must carry service with the same value, here checkout-api. The AI SRE guide shows how to key every source by one service label.

4. Start the MCP endpoint so your agent can read the timeline:

   tares mcp

   Per-client setup is in the AI SRE guide.

5. Ask for the changes before the symptom. For example:

   Use tares: the disk on checkout-api started filling up. What changed in the hour before the first disk event?

6. Read the event just ahead of the symptom. Find the first disk event on the timeline, then look at the commit, push, merged pull request or deploy immediately before it. Open its url label to land on the change in GitHub, and check author, title and sha to tell who to ask.

To be told about merges as they happen, add a trigger on the github source that filters event_type equal to pull_request and action equal to merged, as shown on the GitHub connector page.

What you get

• One timeline per service where the disk symptom and the changes that preceded it sit side by side, in order.
• A named candidate: the commit, push or merged pull request closest before the first disk event, with its author, branch, sha, title and link.
• With a token, the list of files each commit touched, so you can see whether it changed logging, retention, caches or a scheduled job.
• The same event types whether you use a token or the App, so a trigger you write keeps working if you switch credentials later.
• A conclusion your agent can write back onto the timeline, so the next investigation starts from it.

Timing matters when you read the result. A token source polls every 2 minutes, so a commit can appear a little after it landed. The first poll imports recent commits but no old pull requests, and each poll fetches 20 commits by default (limit). A disk usually fills slowly, so check changes from hours or days back, and raise limit if your repository is busy.

When something else fits

• If the cause was not a code change, such as a traffic spike or data growth, the commits give you nothing to blame. The metric and log events on the same timeline are then the better place to look.
• If your releases ship from a pipeline, add a webhook source that posts a deploy event on every deploy, so the timeline shows when a change reached production, not only when it was merged.
• For a quick manual check on one repository, GitHub’s own commit history works, but it does not show the disk symptom next to the change.

Related