How do I show GitHub App events next to CloudWatch alarms for an AI SRE?

Tares shows GitHub App events and CloudWatch alarms on one timeline when both carry the same repo label value, so a merge or push reads first and the alarm after it. GitHub App events already carry a repo label. You give the CloudWatch alarm source the same label with the same value. CloudWatch reaches Tares through the webhook connector and an EventBridge setup, because Tares has no connector of its own for CloudWatch today.

How it works

Tares builds one timeline per label value, with every source that carries that label merged on one clock. This is how the AI SRE guide keys metrics, logs and alerts by service. Here you key the change and the alert by the repository that holds the service.

• The change side. With the GitHub App, events arrive as they happen: pull requests, pushes, reviews, issues, releases and CI runs. Every event carries a repo label such as acme/checkout-api. A merged pull request has event_type pull_request and action merged. A push has event_type push, and a CI run has event_type workflow_run.
• The alert side. EventBridge posts each CloudWatch alarm state change to a webhook source. The payload has no repository field, so you set the repo label on the source as a constant. Every alarm that source receives then lands on that repository’s timeline.
• The order. The alarm source reads its timestamp from the payload’s top-level time field with event_time_field. A merge at 14:02 and an alarm at 14:04 sit on the timeline in that order, so an agent reading it sees the change first and the alert after.

Each webhook source has its own ingest URL, so use one alarm source per repository you want to correlate.

Set it up

1. Connect the GitHub App. On Tares Cloud, choose Connect GitHub in your workspace settings and pick the repositories. On a self-hosted Tares, open Settings > GitHub, choose Create GitHub App, then Install on GitHub. Tares creates the github source for you. GitHub must be able to reach a local Tares, so run a tunnel and use its address as the public URL:

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

2. Create a webhook source for the alarms of one service, in Sources > Add source > webhook. Make repo the primary label with the repository as its constant value, exactly as GitHub writes it. Add a second label for the alarm name, which is a one-level dotted field.

- name: checkout-alarms
  connector: webhook
  config:
    event_time_field: time
    labels:
      - { name: repo, const: acme/checkout-api, primary: true }
      - { name: alarm, field: detail.alarmName }

3. Copy the ingest endpoint from the source page. In EventBridge, create an API destination whose endpoint is that Tares ingest URL and whose method is POST. The URL must be public HTTPS.
4. Give the API destination a connection, which EventBridge requires. Use API key authorization with header name Authorization and the value Bearer followed by an ingest-scoped API key. The key value only matters when Tares has auth on.
5. Create a rule on the default event bus that matches source aws.cloudwatch and detail-type CloudWatch Alarm State Change, and set the API destination as its target.
6. Check the mapping. Wait for an alarm to change state, then open the alarm source’s Recent events and Fields. Confirm the repo label reads the same value as on the github source, then open that repository’s timeline.

If you want the alarm state as a label or in a text template, note that detail.state.value is two levels deep. Flatten it with an input transformer on the rule target first.

Do not route the alarm through an SNS action. An SNS HTTPS subscription cannot send a custom header, and its subscription confirmation message would never be confirmed.

What you get

• One timeline per repository, with GitHub App events and CloudWatch alarms merged on one clock.
• The change first and the alert after, so an agent investigating an alarm sees the merged pull request, push or CI run that came before it.
• Alarms that keep their full payload, stored lossless, with the alarm name available as a label.
• Triggers and agents that work from the same correlated read as in the rest of the AI SRE setup.

When something else fits

• If your alarm names or other fields already match a label on the change events, use that field as the label instead of a constant, so one source covers several services.
• If your alerts come from Prometheus rules or Alertmanager, use those connectors instead. They keep alerting where it is and need no EventBridge setup.
• If you only want the changes, the GitHub App source alone is enough.

Related