How do I show GitHub App events next to PagerDuty incidents for an AI SRE?

Tares shows GitHub App events next to PagerDuty incidents when both sources carry the same label with the same values. Each service then gets one timeline, so a merged pull request or push appears first and the incident after it. The GitHub App is a connector in Tares, and PagerDuty reaches Tares through the webhook connector and a vendor setup.

How it works

Tares builds one timeline per label value. Sources that carry the same label land on the same timeline, merged on one clock. The AI SRE guide does this with a service label shared by metrics, logs and alerts.

The two sources here arrive differently:

• GitHub App events arrive as GitHub webhooks, as they happen. The github source covers every repository the App is installed on. Its events include pull requests, pushes, reviews, issues, releases and CI runs (workflow_run). Each event carries labels such as repo, action, author, branch, sha and title. Read more on the GitHub connector page.
• PagerDuty incidents arrive through a v3 webhook subscription that delivers to a Tares ingest URL. Tares has no connector of its own for PagerDuty today, so you use the webhook connector with a PagerDuty setup. The payload is stored lossless, and you declare labels to map payload fields into the envelope.

The join works when the label name and the label values match on both sides. The GitHub events already carry repo. On the PagerDuty source, declare a label with the same name and fill it from a payload field that holds the same value. Labels on a webhook source read top-level fields or one-level dotted fields such as event.event_type. Fields nested deeper are not read for labels.

PagerDuty sets the event type inside event.event_type, for example incident.triggered. The webhook connector reads event_type_field from top-level fields only, so you give the source a fixed event_type.

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 and pick the repositories. Tares creates the github source for you.

2. On a self-hosted Tares running locally, make it reachable from GitHub, because deliveries start once Tares is reachable:

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

3. Create a webhook source for PagerDuty under Sources > Add source > webhook, or with POST /api/sources. Give it a fixed event type and declare the shared label, marked primary. The field below is a placeholder. Use a one-level payload field that holds the same value as the GitHub repo label, and keep the label name repo:

   - name: pagerduty-incidents
     connector: webhook
     config:
       event_type: pagerduty_event
       labels:
         - { name: repo, field: your_field, primary: true }
         - { name: pd_event, field: event.event_type }

   Copy the ingest endpoint from the source page. The pd_event label shows how a one-level dotted field is read.

4. In PagerDuty, create a v3 webhook subscription, in the console or with the Webhook Subscriptions API, whose delivery URL is the Tares ingest URL. Choose events such as incident.triggered and incident.resolved, and the scope: account, team or service.

5. If Tares has auth on, add a custom header to the delivery method: Authorization: Bearer followed by an ingest-scoped API key. This header is the credential for the PagerDuty source. Do not set signature_scheme on this source. PagerDuty signs with a v1= prefixed header that hmac_sha256 does not accept.

6. Check the mapping. After a delivery, open Recent events on the PagerDuty source and check Fields to see which payload fields arrive. Confirm that your shared label has values.

7. Open Explore and pick a value of the shared label. The merged pull request, push or CI run and the PagerDuty incident now sit on one timeline, with the change before the alert.

What you get

• One timeline per service or repository, where GitHub App events and PagerDuty incidents share a clock. An agent reads a pull request merged at one time and an incident triggered shortly after, in order.
• An AI SRE that starts from the change. As the AI SRE guide says, most real root causes are a change, so a deploy or merge next to the alert is the evidence an incident agent needs.
• Triggers that work on both sources. A trigger can watch the PagerDuty source and wake your agent with the correlated timeline, GitHub changes included.
• Resolved incidents on the same timeline, because incident.resolved deliveries arrive through the same subscription.
• Pull request events that stay the same if you later change how GitHub is connected. The token path and the App produce the same event types for pull requests.

When something else fits

• If you do not run the GitHub App, a personal token source polls commits and pull requests every 2 minutes. It does not deliver pushes, reviews, issues or CI runs.
• If your PagerDuty payload has no usable one-level field for the shared label, the incidents stay on a timeline of their own. Pick another label that both sides can carry, or put the value in a field PagerDuty sends at the top level of your payload.

Related