How do I show Vercel deploys next to Datadog monitors for an AI SRE?

Tares shows Vercel deploys next to Datadog monitors by giving both sources the same service label, so one timeline per service puts the change before the alert. Vercel reaches Tares through its own connector, a log drain. Datadog reaches Tares through the webhook connector and a Datadog webhook setup, because Tares has no connector of its own for Datadog today. Your AI SRE then reads one clock per service and sees the deploy first and the monitor firing after it.

How it works

Tares builds one timeline per entity, and an entity is whatever your primary label says it is. If two sources carry the same primary label with the same value, their events merge on one clock. That is what puts a deploy and an alert in order. For background on this model, see Build an AI SRE.

• Vercel side. The Vercel connector receives a Vercel log drain, one event per log entry. Entries carry the labels project, environment, source (including build), deployment and branch. You read the primary label from project, but name it service.
• Datadog side. The webhook connector stores the JSON that a Datadog webhook posts, lossless. You write the payload in Datadog from variables such as $ALERT_ID, $EVENT_MSG and $LINK, so you decide which field carries the service name. Keep the payload flat, because event_type_field and text_template read top-level fields only.
• The match. The Datadog service value must equal the Vercel project name, for example checkout on both sides. Tares joins on equal label values, so a mismatch gives you two separate timelines.

Set it up

1. Create the Vercel source with a primary label named service, read from the project field. Create it in Sources, Add source, vercel, or post the same object to POST /api/sources. The response includes the ingest_key.

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

2. Create the Datadog source as a webhook source with a primary service label. Your Datadog payload must put the service name in a top-level service field.

- name: datadog-monitors
  connector: webhook
  config:
    labels:
      - { name: service, field: service, primary: true }

3. Point Vercel at the Vercel source. In Vercel, open Team Settings, Log Drains, Add Log Drain. Set the endpoint to the source’s ingest URL and the delivery format to JSON. The ingest endpoint must be publicly reachable, so use a deployed instance or a tunnel. A bare localhost daemon does not receive drains.
4. Point Datadog at the webhook source. In Datadog, open the Webhooks integration and add a webhook whose URL is the webhook source’s ingest URL. Write the payload as flat JSON from Datadog variables, with the service name in the service field.
5. Call the webhook from your monitors. Put @webhook- followed by the webhook’s name in the monitor message so the monitor posts to Tares.
6. Add credentials if Tares has auth on. Add an Authorization: Bearer header holding an ingest-scoped API key. In Datadog, set it as a custom header in JSON. In Vercel, set it as a custom header on the drain. Without auth on, you need no header.
7. Check the match. Open Recent events on each source, and Fields to confirm service is filled. Then open Explore and pick the service. Deploy entries and monitor alerts should appear on the same clock.

What you get

• One timeline per service with Vercel entries and Datadog monitor events merged, so the order reads change first, alert after.
• Vercel entries that keep environment, source, deployment and branch, so you can tell a production build from a preview.
• An AI SRE that starts from that merged read. A connected agent can ask what happened to a service in the last 15 minutes and answer from the correlated timeline. A trigger on the Datadog source can wake an agent with the same timeline attached.
• Datadog stays your alerting system. Tares ingests what fires and correlates it with the change.

When something else fits

• If your deploys run through GitHub rather than Vercel, the GitHub connector brings in pushes, releases and CI runs. Those carry a repo label, so map them to your service label the same way.
• If a deploy is not visible in Vercel log entries, post a deploy event from your CD pipeline to a webhook source with the same service label instead.
• If you prefer to keep monitors in Prometheus or Alertmanager, those have their own connectors and need no Datadog webhook.

Related