How do I show GitHub commits and pull requests beside Grafana Loki logs for an AI SRE?

Tares shows GitHub commits and pull requests beside Grafana Loki logs when you give the GitHub source and the Loki source the same service label. Tares then merges both into one timeline for that service, in time order. Your AI SRE reads that timeline and checks whether the first error lines start after a commit or a merged pull request.

How it works

Tares builds one timeline per service from every source that carries the same primary service label. Metrics, logs, alerts and change events sit on one clock, and an agent gets that merged read instead of querying each system separately. The Build an AI SRE guide shows this with its demo sources, which all share service.

For this question, two sources feed the timeline:

• Grafana Loki logs. The Loki connector polls a Loki instance, including Grafana Cloud, with a LogQL query. It polls every 5 seconds by default. Its settings are url, query, bearer_token, username, password, tenant_id, match, drop and key.
• GitHub commits and pull requests. The GitHub connector with a personal token polls a repository every 2 minutes by default. It reports commits and pull requests opened, merged or closed. With the GitHub App, events arrive as they happen by webhook and include pushes, reviews, releases and CI runs. See GitHub for both paths.

GitHub events carry labels such as repo, action, author, branch, sha, title and url. A commit has event_type set to commit, a push has push, and a pull request has pull_request. A pull request that merged reads merged in action. The agent sees who changed what, and when, next to the log lines of the same service.

Set it up

1. Pick the service name your logs use, for example checkout. Use the same value on every source for that service.
2. Create the Loki source from Sources > Add source. Set url and query so the LogQL query selects that service’s log lines. Add bearer_token, or username and password, and tenant_id if your Loki needs them. Give the source a labels entry named service, marked primary, with the value checkout.
3. Create a GitHub source for the repository that deploys that service. This example uses a personal token credential from Settings > GitHub and adds a constant service label next to the repo label:

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

4. Repeat step 3 for each repository behind the service. A token source covers one repository, so a constant service label fits it well. The GitHub App puts every installed repository in one source, so a single constant would label them all the same.
5. Check the result in Explore. Pick the service and confirm that log lines, commits and pull requests appear on one clock.
6. Connect your MCP client so an agent can read the timeline. Start the endpoint in a second shell:

tares mcp

7. Ask: “Use tares: did the errors for checkout start after the last merge?” The client calls read with the service and answers from the merged timeline.

To wake an agent on a change, build a trigger on the github source. This filter set from the GitHub page fires once per merged pull request:

- 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

What you get

• One timeline per service where a commit or merged pull request sits between the log lines before it and the log lines after it.
• An agent that can answer “did the errors start after the change?” by comparing timestamps in a single read, with the author, branch, sha, title and link of the change in hand.
• The same GitHub events whether you use a token or the GitHub App, so triggers written on event_type and action keep working if you switch later.
• Findings the agent writes back to the same service timeline, so the next investigation starts from the previous conclusion.
• Optional triggers on merged pull requests, so an agent wakes when a change lands instead of waiting for an alert.

When something else fits

• If you want pushes, reviews, releases or CI runs next to your logs, use the GitHub App path instead of a token. It delivers them as they happen, and it needs a public address GitHub can reach.
• If your deploys do not come from a commit or merge, add a webhook source that your pipeline calls on every deploy. It lands on the same service timeline.

Related