How can an AI SRE tell whether GitHub commits and pull requests made the errors in Docker container logs start?

Tares puts GitHub commits and pull requests and your Docker container logs on one per-service timeline, so an AI SRE can read when a change landed next to when the error lines began. You tail the container with the docker_logs connector, connect GitHub with the github connector, and give both sources the same service label. Your agent then reads one correlated timeline and writes its conclusion back as a finding.

How it works

Tares merges sources into one timeline per service when they carry the same service label. The AI SRE guide shows how the logs, metrics and alerts of one service share a clock. A change source on the same timeline lets the agent see the pattern “deploy landed 14:02, errors started 14:04”.

• Docker logs. The Docker logs connector tails a running container and stores one event per line. All lines are kept by default. The optional match and drop regex filters narrow that down.
• GitHub changes. The GitHub connector delivers pull_request events with the action opened, merged or closed, plus commit events with a personal token and push events with the GitHub App.
• Labels on every change. Each GitHub event carries repo, action, author, branch, sha, url and title where they apply. A merged pull request reads merged.
• How fast changes arrive. With the GitHub App, events arrive as they happen by webhook. With a personal token, Tares polls every 2 minutes by default.
• How the agent reads it. Your connected agent calls read with the service name and gets the correlated timeline. A trigger can also wake a Tares agent that reads the same timeline.
• What is written back. The agent writes its finding onto the service’s timeline. The next investigation starts from that finding instead of from scratch.

Set it up

1. Start Tares and the MCP endpoint, each in its own shell, so your agent can read the timeline.

tares up
tares mcp

2. Add the Docker logs source under Sources > Add source > docker_logs, or ask a connected agent to find your containers. Set container to the container name from docker ps, and give the source a primary service label. Tares needs access to the Docker daemon, so run taresd on the host or mount the Docker socket.

- name: logs
  connector: docker_logs
  poll: 5s
  config:
    container: tares-demo-api-server   # the container name (docker ps)
    labels:
      - { name: service, const: api-server, primary: true }

3. Connect GitHub. On Tares Cloud, choose Connect GitHub in your workspace settings. On a self-hosted Tares, open Settings > GitHub and choose Create GitHub App. For a personal token, choose Add a personal token, then add one source per repository. Give the repository’s source the same service label value as the container.

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

4. Check both sources. For Docker, open the source in the console, where Recent events shows lines on the next poll. For GitHub, a new commit or pull request shows up as an event on the source.

5. Connect your MCP client, then ask it about the incident window. For example:

Use tares: what happened to api-server in the last 15 minutes?

6. To have Tares wake an agent when errors appear, build a trigger over the log source. The AI SRE guide shows how a trigger wakes an agent that reads the timeline and writes a finding.

What you get

• One timeline per service where each container log line sits beside the commits, pushes and merged pull requests of the repository behind it.
• The change identity right on the event: sha, author, title, url, branch and action. When you suspect a change, you can open it on GitHub from the same record.
• Log lines you can narrow with a match regex such as ERROR, or thin out with drop, for example to remove access logs.
• A finding written back to the timeline, so the next person or agent who asks about the service starts from the earlier conclusion.
• The same GitHub events whether you use the App or a personal token, so a trigger written for one keeps working when you switch.

When something else fits

• If your changes ship through a CD pipeline rather than GitHub, add a webhook source that posts a deploy event per release, as the AI SRE guide describes. The deploy event then shares the service timeline with the logs.
• If the containers are not on a host where Tares can reach the Docker daemon, send the logs through OTLP instead. The GitHub connector works the same either way.

Related