How do I show Vercel deploys next to PagerDuty incidents for an AI SRE?

Tares shows Vercel deploys next to PagerDuty incidents when both sources carry the same service label, so one timeline reads change first, alert after. Vercel reaches Tares through the vercel connector, and PagerDuty through the webhook connector with a PagerDuty v3 webhook subscription. Your agent then reads one merged timeline per service, as described in AI SRE.

How it works

Tares builds one timeline per entity by joining sources on a shared label. Events from every source that carries the same label value land on one clock, and an AI SRE agent reads that single timeline.

• Vercel deploys. A Vercel log drain posts to a vercel source. Each log entry is one event keyed by project, with environment and source as labels. Build output shows up with source set to build, and entries also carry deployment and branch.
• PagerDuty incidents. Tares has no connector of its own for PagerDuty today. Incidents reach Tares through the webhook connector and a PagerDuty v3 webhook subscription. The payload is stored lossless, and you declare labels to map fields into the envelope.
• The shared label. Name the primary label service on both sources. A deploy at 14:02 and an incident at 14:04 then sit on the same service timeline in that order, so the agent sees the change before the alert.

The webhook connector reads top-level fields for event_type_field, so the PagerDuty source uses a fixed event_type. Labels can use one-level dotted fields such as event.event_type. Deeper fields in the PagerDuty payload, such as the service name, are out of reach for a label. Scope the subscription to one service and give the label a constant value.

Set it up

1. Start Tares and make the ingest endpoint reachable from the internet. Vercel and PagerDuty both deliver from their clouds, so a bare localhost daemon does not receive them. Use a deployed instance or a tunnel.

   tares up

2. Create the vercel source with Sources > Add source > vercel, or ask a connected agent to create it. Map the project field to a service label so it matches your PagerDuty label. Copy the ingest endpoint from the source page.

   - name: web-logs
     connector: vercel
     config:
       labels:
         - { name: service, field: project, primary: true }
         - { name: environment, field: environment }
         - { name: source, field: source }

3. In Vercel, open Team Settings > Log Drains > Add Log Drain. Set the endpoint to the ingest URL and the delivery format to JSON. Tares echoes back the x-vercel-verify header from Vercel’s verification request. Name the Vercel project after the service, so the label values match.

4. Create the PagerDuty source with Sources > Add source > webhook. Use a fixed event_type and a constant service label whose value is the Vercel project name. Copy its ingest endpoint.

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

5. In PagerDuty, create a v3 webhook subscription, in the console or with the Webhook Subscriptions API, whose delivery URL is the PagerDuty source’s ingest URL. Choose events such as incident.triggered and incident.resolved. Set the scope to the service that matches your constant label.

6. If Tares has auth on, both senders need a Bearer Authorization header holding an ingest-scoped API key. Add it as a custom header on the Vercel drain and on the PagerDuty delivery method. Do not set a signature scheme on the PagerDuty source. The Bearer header is its credential.

7. Check Recent events on each source, then ask your connected client what happened to the service in the last 15 minutes. The answer reads deploys and incidents from the same timeline.

What you get

• One timeline per service where a Vercel build or deployment appears before the PagerDuty incident it may have caused.
• An agent that starts from the change, because both signals sit on one clock and share one label.
• PagerDuty resolutions on the same timeline as the incident, because the subscription can send incident.resolved as well.
• Triggers and agents that key on service across both sources, as in the rest of the AI SRE guide.

When something else fits

• If you need the pull request or commit behind a deploy, add the GitHub connector. Its events carry repo, branch and sha labels, so they can join the same service timeline.
• If your deploys do not run through Vercel, post them from your CD pipeline to a webhook source with a service field, as the vercel connector page’s sibling approach.

Related