How do I show GitHub App events next to Sentry issue alerts for an AI SRE?

Tares puts GitHub App events and Sentry issue alerts on one timeline when both carry the same label for the service. The GitHub App source arrives with a repo label on every event, so you declare a matching label on a webhook source that receives Sentry. Merges, pushes and CI runs then sit before the alert in time order, and your AI SRE reads change first, alert after.

How it works

Two sources feed the same timeline, and a shared label lines them up.

• GitHub App events. Connecting the GitHub App creates a github source. Pull requests, pushes, reviews, releases and CI runs arrive as they happen by webhook. Every GitHub event carries labels such as repo, action, author, branch and sha when they apply.
• Sentry issue alerts. Tares has no connector of its own for Sentry today. Sentry reaches Tares through the webhook connector and a Sentry-side integration. The webhook source stores each payload lossless and maps the fields you declare as labels.
• The shared label. Tares merges sources that carry the same label onto one timeline per entity, on one clock. The GitHub events already carry repo, so you give the Sentry source a repo label with the same owner/name value. Both streams then land on one timeline.
• Authentication. Sentry signs each delivery with an HMAC signature, and that signature is the credential. The Sentry source needs no Tares API key. GitHub deliveries are checked against the App’s webhook secret before anything is stored.

The AI SRE guide describes the same pattern with a service label and a deploy webhook. Use whichever label name your other sources already share.

Set it up

1. Connect the GitHub App. On Tares Cloud, open your workspace settings, choose Connect GitHub, pick the organization and repositories, and confirm on GitHub. On a self-hosted Tares, open Settings > GitHub, choose Create GitHub App, confirm on GitHub, then choose Install on GitHub. Your instance must be reachable from GitHub, so a local tares up needs a tunnel:

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

2. Create the Sentry webhook source. Go to Sources > Add source > webhook and declare a label that matches the GitHub events. This example keys the Sentry alerts to the acme/checkout-api repository and reads the event type from the top-level action field:

- name: sentry-alerts
  connector: webhook
  config:
    event_type_field: action
    signature_scheme: hmac_sha256
    signature_header: Sentry-Hook-Signature
    signing_secret: your-sentry-client-secret
    labels:
      - { name: repo, const: acme/checkout-api, primary: true }

3. Copy the ingest endpoint. Save the source and copy its ingest endpoint from the source page.
4. Add the integration in Sentry. Under Settings, Developer Settings, add an integration and set its Webhook URL to the Tares ingest URL. Subscribe it to the resources you want, such as issues or errors, and turn on Alert Action so alert rules can use it.
5. Paste the Client Secret. Copy the integration Client Secret into the source as the signing secret, replacing the placeholder above. The signing options are described in the release notes, not on the webhook connector page.
6. Check the result. Open the timeline for the repository, or use Recent events on the Sentry source, and confirm that GitHub events and Sentry alerts appear together.

With several services, add one Sentry source per service and give each its own repo value.

What you get

• One timeline per repository where a merged pull request, a push or a failed CI run appears before the Sentry alert it may have caused.
• Alerts and changes ordered by time on one clock, so your agent starts from the change instead of searching for it.
• GitHub events that stay labeled by repo, action, author, branch, sha and title, so triggers and filters over them keep working. Sentry alerts join them through the shared repo label.
• Signed Sentry deliveries, with no Tares API key to manage on that source.
• The same evidence for a connected MCP client and for a Tares agent woken by a trigger.

When something else fits

• If your alerts come from Prometheus or Alertmanager, use prometheus_alerts or alertmanager instead of a Sentry webhook, and keep the same shared label.
• If you only need commits and pull requests from one repository and cannot install an App, the GitHub personal token path polls every 2 minutes, but it brings no pushes, reviews or CI runs. See the GitHub connector for both paths.

Related