How can an AI SRE connect a change in GitHub commits and pull requests to what changed in Postgres tables?

Tares connects GitHub commits and pull requests to Postgres row changes by putting both sources on one timeline under the same label value. The agent reads the order of the events on one clock. It can then say whether the data changed after the commit or deploy and cite both lines, or say that it did not.

How it works

Tares keeps one timeline per entity. Any sources that carry the same label value are merged onto that timeline, so the AI SRE guide keys metrics, logs and alerts by one service label. You use the same mechanism for change and data events.

• The GitHub connector produces change events. With a personal token it polls every 2 minutes and reports commits and pull requests opened, merged or closed. With the GitHub App, events arrive as they happen by webhook, including pushes, reviews, releases and CI runs.
• The Postgres connector produces data events. It polls a table incrementally, one event per new or changed row, using a cursor column that only grows, such as updated_at.
• Each source has a primary label. When the GitHub label and the Postgres label share a name and a value, both event streams land on the same timeline.
• Each event has an event time. For Postgres, time_column sets it, and by default it is the cursor if the cursor is a timestamp. GitHub events carry the labels sha, title, author, action and url, so a commit or merged pull request is identifiable on the line.

When the agent reads the timeline, a merge or push and a row change are lines on one clock. Because the order is explicit, the agent can say the status change came after the merge and cite both lines. If the rows changed before the merge, or never changed, it can say that too.

Set it up

1. Install Tares and start it.

uv tool install tares     # or: brew install glassflow/tap/tares
tares up

2. Add the GitHub source. The GitHub App is the recommended path: on Tares Cloud choose Connect GitHub, and on a self-hosted Tares open Settings > GitHub and choose Create GitHub App. For a personal token, add one source per repository and give it a label that names the entity, here a constant service label:

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

3. Add the Postgres source with the same label name and the same value. Pick a cursor column that also moves on updates, such as updated_at, so changed rows arrive and not only inserts. In the console you can use Sources > Add source > Postgres and Discover to list tables and propose the cursor.

- name: orders
  connector: postgres
  poll: 10s
  config:
    dsn: postgresql://user:pass@host:5432/appdb
    table: orders
    cursor_column: updated_at
    columns: id,tenant_id,status,amount,updated_at   # empty = every column
    labels:
      - { name: service, const: checkout-api, primary: true }
      - { name: status, field: status }

4. Open Explore and pick checkout-api. GitHub events and order rows appear merged on one clock. On the Postgres source, Recent events shows rows on the next poll and Fields reports each column’s coverage.

5. Connect your agent over MCP and ask the question in plain words.

tares mcp

Use tares: did orders change after the last merged pull request on checkout-api?

The agent reads the correlated timeline and answers from the lines on it. To wake an agent on every merge, 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 where a commit, a merged pull request or a push sits next to the rows it may have changed.
• An answer with a direction. The agent says the data changed after the change, or that it did not, and cites the GitHub line and the Postgres line.
• The same events for a token and for the App, so a trigger you write on pull requests keeps working if you switch credentials.
• Pull request and commit lines that carry sha, title, author and url, so a finding points to the exact change.
• Findings the agent writes back to the timeline, so the next investigation starts from the last conclusion.

Keep two behaviors in mind when you read the order. Postgres events are as fine as your poll interval and cursor column: a cursor on id sees inserts only, while updated_at also sees updates. GitHub with a token reports a pull request only when it is opened, merged or closed, and a pull request reopened between two polls is not reported. The first token poll imports recent commits and no old pull requests.

When something else fits

• If you run the GitHub App, it gives you pushes, reviews, releases and CI runs as they happen, which suits sub-minute ordering better than a 2 minute token poll.
• If your deploys do not show up as GitHub events, send them to the AI SRE timeline through a webhook source with the same label, as the guide shows.
• If you want a reading of a single repository or table on its own, you do not need a shared label. Add the source and read its timeline directly.

Related