How do I show GitHub commits and pull requests next to CloudWatch alarms for an AI SRE?

Tares puts GitHub changes and CloudWatch alarms on one per-service timeline when both sources carry the same service label. You connect GitHub with the github connector and send CloudWatch alarms through the webhook connector and an EventBridge setup. The timeline then reads change first, alert after, and your agent reads it as one piece of evidence.

How it works

Tares builds one timeline per service from every source that carries the same service label, merged on one clock. The Build an AI SRE guide uses this for metrics, logs and alerts. A deploy or commit landing at 14:02 and an alarm at 14:04 appear in that order, so the agent sees the likely cause before the symptom.

Two sources feed it here:

• GitHub changes. The github connector reads commits and pull requests. With a personal token it polls every 2 minutes, one source per repository. See the GitHub connector page for the GitHub App path, which delivers pull requests, pushes, reviews and CI runs as they happen.
• CloudWatch alarms. Tares has no connector of its own for CloudWatch today. Alarms reach Tares through the webhook connector and a vendor setup in EventBridge: an API destination posts each alarm state change to the source’s ingest URL as JSON.

The join is the label. Give the GitHub source and the CloudWatch webhook source a label with the same name and the same value, for example service with the value checkout, and mark it primary on both.

Set it up

1. Add the GitHub source. Create a fine-grained token with Metadata, Contents and Pull requests read, add it under Settings > GitHub, then add a source for the repository. Set the service label as a constant, since a token source covers one repository.

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

2. Add the CloudWatch webhook source. In Sources, add a webhook source with the same service label and value. The alarm name is a one-level dotted field, so it works as a second label. Copy the ingest endpoint from the source page.

- name: checkout-alarms
  connector: webhook
  config:
    event_type_field: detail-type
    labels:
      - { name: service, const: checkout, primary: true }
      - { name: alarm, field: detail.alarmName }

3. Create the EventBridge API destination. Set its endpoint to the Tares ingest URL, which must be public HTTPS, and its method to POST.
4. Give it a connection. EventBridge requires one on every API destination. Use API key authorization with header name Authorization and the value Bearer followed by an ingest-scoped API key. The key only matters when Tares has auth on.
5. Create the rule. On the default event bus, match source aws.cloudwatch and detail-type CloudWatch Alarm State Change, and set the API destination as the target. Use one source and one rule per service, so each alarm carries its own service label.
6. Keep the state flat if you need it. The alarm state, detail.state.value, is two levels deep. If you want it as a label, flatten it with an input transformer on the rule target.
7. Check the result. Open the source page and look at Recent events and Fields to confirm the alarm payload arrives. Then open Explore, pick the service, and read commits, pull requests and alarms on one clock. Your agent gets the same view when it calls read with the service.

If you run Tares locally and use the GitHub App instead of a token, GitHub and EventBridge both need a public address, so run a tunnel as the GitHub page describes.

What you get

• One timeline per service where a pull request merge or a commit sits before the alarm it may have caused.
• Alarm events with the alarm name as a label and the full EventBridge payload stored lossless.
• GitHub events with labels such as repo, author, branch, sha, title and, for pull requests, action.
• Triggers over the alarm source that wake your agent with the correlated timeline, so the first read already includes recent changes.
• A shared primary label, so adding more services means repeating the same two sources with a different service value.

When something else fits

• Use the GitHub App instead of a token when you want pushes, reviews and CI runs as they happen, or one source across many repositories. Then the constant service label no longer fits, so label by repo.
• CloudWatch alarm actions that publish to SNS do not fit this route. An SNS HTTPS subscription cannot send a custom header and its confirmation message would never be confirmed, so use the EventBridge route above.
• If the alarm should only wake an agent and you do not need the change history, the webhook source alone is enough.

Related