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

Tares shows GitHub changes and PagerDuty incidents on one timeline when both sources carry the same service label. PagerDuty reaches Tares through the webhook connector and a vendor setup, and GitHub commits and pull requests come from the github connector. Your AI SRE then reads the change first and the alert after, in time order, for that service.

How it works

Tares builds one timeline per service from every source that carries the same label. The AI SRE guide keys metrics, logs and alerts on a service label for this reason, and the same rule applies here.

• PagerDuty incidents arrive through the webhook connector. Tares has no connector of its own for PagerDuty today, so you create a v3 webhook subscription in PagerDuty that delivers to a Tares ingest URL.
• GitHub commits and pull requests arrive through the github connector. With a personal token, each source polls one repository every 2 minutes by default and reports its commits and its pull requests opened, merged or closed.
• The shared label is a service label you declare on both sources. Tares merges the events on one clock, so a commit or merged pull request that lands before an incident sits above it on the timeline.

The PagerDuty payload nests its fields under event. The webhook connector reads event_type_field from top-level fields only, so you set a fixed event_type on the source and read PagerDuty fields as one-level dotted labels such as event.event_type. You set the service label in Tares as a constant, so every event on a source carries the same service value.

Set it up

1. Create the PagerDuty source. Add a webhook source with a fixed event type, a primary service label and a label for the incident event. Replace checkout with your service name.

- name: pagerduty-incidents
  connector: webhook
  config:
    event_type: pagerduty_incident
    labels:
      - { name: service, const: checkout, primary: true }
      - { name: incident_event, field: event.event_type }

2. Copy the ingest URL. Open the source page in Sources and copy the ingest endpoint.

3. Create the subscription 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 the events you want, such as incident.triggered and incident.resolved, and the scope: account, team or service.

4. Add the credential if Tares has auth on. Add a custom header to the delivery method: an Authorization Bearer header holding an ingest-scoped API key. Do not set signature_scheme on this source. PagerDuty signs with a v1= prefixed header that hmac_sha256 does not accept, so the Bearer header is the credential.

5. Add the GitHub source with the same label. Create a github source for the repository that ships this service. Pick a GitHub credential from Settings > GitHub, and give the source the same service value.

- 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 }

6. Check the result. On the PagerDuty source, open Recent events and Fields to confirm deliveries arrive. Then open Explore, pick checkout, and confirm commits, pull requests and incidents appear together. A connected agent reads the same merged timeline for that service.

What you get

• One timeline per service that holds PagerDuty incidents next to the commits and pull requests of the repository behind it.
• A time-ordered view, so an agent sees a merged pull request, then the incident that followed it.
• GitHub labels you can use alongside the service label: repo, action, author, branch, sha, title and url.
• An AI SRE that starts an investigation from the most recent change instead of asking you what shipped.
• One service label that works the same for triggers, so a trigger over both sources keyed by service sees alerts and changes together.

When something else fits

• If you want GitHub events as they happen, connect the GitHub App instead of a personal token. It delivers pushes, pull requests, reviews and CI runs by webhook, while a token source polls on a 2-minute cycle.
• If your real changes are deploys rather than commits, post each deploy from your CD pipeline to a second webhook source with the same service label, as the AI SRE guide shows.

Related