How do I pair PagerDuty incidents with logs from Vercel projects for an AI SRE?

Tares pairs PagerDuty incidents with Vercel logs when both sources carry the same service label, so one timeline per service holds the incident and the log lines from the same window. PagerDuty reaches Tares through the webhook connector and a PagerDuty v3 webhook subscription, because Tares has no connector of its own for PagerDuty today. Vercel logs arrive through the vercel connector and a Vercel log drain. Your agent then reads one correlated timeline instead of two tools.

How it works

Tares correlates sources by label. When two sources share a label name and value, their events sit on one clock for that entity. This is how the AI SRE guide wires metrics, logs and alerts together, keyed by service.

For this pairing:

• PagerDuty posts each incident event to a webhook source. Webhook labels read one-level dotted fields such as event.event_type. PagerDuty’s own payload nests the service deeper than that, so scope each subscription to one PagerDuty service and give that source a constant service label.
• Vercel sends one event per log entry through the vercel connector. Its key is project, taken from the payload’s projectName, else projectId. A single drain can carry several projects, and each appears as its own entity. Name the label service and read it from project, so a Vercel project and the PagerDuty service share a value.
• A trigger on the PagerDuty source wakes your agent when an incident event arrives. The agent reads the timeline for that service and sees the incident next to the Vercel log lines from the same window.

The PagerDuty webhook source uses a fixed event_type, because event_type_field reads top-level fields only. PagerDuty signs deliveries with a v1= prefixed header that the hmac_sha256 option does not accept, so do not set signature_scheme. The credential is the Authorization Bearer header.

Set it up

1. Pick one value per service. Use the same lowercase name in both places, for example checkout. It must match the Vercel project name and the constant label on the PagerDuty source.
2. Create the Vercel source. In Sources, Add source, vercel, or by asking a connected agent to create it, use this config. The label is named service and reads the project field.

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

3. Add the drain in Vercel. Go to Team Settings, Log Drains, Add Log Drain. Set the endpoint to the source’s ingest URL and the delivery format to JSON. Tares echoes back the x-vercel-verify header during Vercel’s verification. The ingest URL must be publicly reachable, so use a deployed instance or a tunnel, not a bare localhost daemon.
4. Create a PagerDuty webhook source for each service. Copy its ingest URL from the source page.

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

5. Create the PagerDuty subscription. In PagerDuty, create a v3 webhook subscription, in the console or with the Webhook Subscriptions API. Set its delivery URL to the ingest URL from step 4. Choose events such as incident.triggered and incident.resolved, and set the scope to the one service the source stands for.
6. Add authentication if Tares has auth on. Add a custom header on the PagerDuty delivery method and on the Vercel drain. It is an Authorization header whose value is Bearer followed by an ingest-scoped API key. Without auth on, you can skip it.
7. Add a trigger on the PagerDuty source. It wakes your agent when an incident event arrives.

- name: pagerduty-incident
  sources: [pagerduty-checkout]
  condition: { aggregate: count, predicate: "> 0", window: 5m }
  cooldown: 5m

8. Check the result. Open Recent events and Fields on each source. Confirm that service reads checkout on both and that the Vercel service coverage is dense. If it reads sparse, pick a denser field as the key or slice by source or environment.

What you get

• One timeline per service, with the PagerDuty incident and the Vercel log lines on the same clock.
• A firing incident that arrives with the logs from the same window, so the agent starts from evidence instead of searching for it.
• Vercel context on every entry: environment (production or preview), source (lambda, build, edge, static, external or redirect), path, host, deployment and branch.
• Incident state on the timeline, because the state label carries incident.triggered, incident.resolved and the other events you subscribed to.
• A path to scale: repeat steps 4 and 5 for each additional PagerDuty service, and keep the one Vercel drain for all projects.

When something else fits

• If the PagerDuty service and the Vercel project do not share a name, set the constant on the PagerDuty source to the Vercel project name, or change the Vercel label, so both sides use one value.
• If your logs come from containers or an OpenTelemetry pipeline instead of Vercel, the same approach works with the docker_logs or otlp connectors, keyed by the same service label.

Related