How do I show Vercel deploys next to CloudWatch alarms for an AI SRE?

Tares shows Vercel deploys next to CloudWatch alarms when both sources carry the same service label, because Tares merges sources that share a label onto one timeline per service. Vercel log drain entries arrive through the vercel connector. CloudWatch alarms reach Tares through the webhook connector and an EventBridge API destination. Your AI SRE then reads the change and the alarm together on one clock.

How it works

Tares builds one timeline per service. Every source that carries the same label, here service, lands on that service’s timeline, merged on one clock. Your agent reads that single timeline, so a change and an alert for the same service sit side by side instead of in two tools. The Build an AI SRE guide describes this correlation in full.

The two sides arrive differently:

• Vercel. The Vercel connector takes a Vercel log drain in JSON. It produces one event per log entry, with project, environment and source labels, plus path, host, deployment and branch. The source label separates entries such as build and lambda, so you can pick out build and deployment activity.
• CloudWatch. Tares has no connector of its own for CloudWatch today. An EventBridge rule posts each alarm state change to a webhook source, which stores the payload lossless. source and detail-type are top-level fields, and detail.alarmName works as a one-level dotted label.

The join is the label. Name it service on both sources and fill it with the same values, for example the Vercel project name.

Set it up

1. Create the Vercel source with a service label. Read the label from the payload’s project field and mark it primary. Save it and copy the ingest URL 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 }

2. Add the log drain in Vercel. Go to 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. The endpoint must be publicly reachable. If Tares has auth on, add an ingest-scoped API key to the drain as a custom header, Authorization: Bearer <key>.

3. Create the CloudWatch webhook source with the same label. The const form below gives every alarm on this source the service name that matches your Vercel project. Use one source per service, or flatten a service field with an input transformer on the rule target.

- name: cloudwatch-alarms
  connector: webhook
  config:
    labels:
      - { name: service, const: web, primary: true }
      - { name: alarm, field: detail.alarmName }

4. Create the EventBridge API destination. Set its endpoint to the CloudWatch source’s ingest URL, which must be public HTTPS, and its method to POST. Give it a connection that uses API key authorization with header name Authorization and the value Bearer followed by an ingest-scoped API key. The key only matters when Tares has auth on.

5. Create the rule. On the default event bus, match source aws.cloudwatch and detail-type CloudWatch Alarm State Change, and set the API destination as the target. Use this route rather than an SNS subscription. An SNS HTTPS subscription cannot send a custom header, and its confirmation message would never be confirmed.

6. Check the mapping. Post a sample body to the ingest URL, then open Recent events and Fields on the source page.

curl -X POST http://localhost:8787/ingest/<ingest_key> \
  -H 'Content-Type: application/json' \
  -d '{"source": "aws.cloudwatch", "detail-type": "CloudWatch Alarm State Change", "detail": {"alarmName": "web"}}'

7. Read it together. Open Explore, pick the service, and both sources appear on its timeline. The Vercel entries and the alarm are in time order on one clock, so you can see whether the build and deployment entries came before the alarm.

What you get

• One timeline for the service with Vercel log entries and CloudWatch alarm events merged on one clock.
• The deployment and branch labels on Vercel entries, so your agent can tie an alarm to a specific deployment.
• Triggers that watch both sources keyed by service, so an alarm can wake an agent that already has the recent deploy activity in its read.
• A path that works with the alarms you already have. You keep CloudWatch alarms as they are, and Tares ingests what fires.

The alarm state sits two levels deep at detail.state.value. If you want it as a label or in text_template, flatten it with an input transformer on the rule target.

When something else fits

• If your alarms reach you through SNS only, the EventBridge route above is the one that works, so move the alarm to an EventBridge rule first.
• If the change you care about is a code merge rather than a deploy, the GitHub connector brings pull requests and pushes, with repo and branch labels, onto the timeline.
• If your deploys do not come from Vercel, a webhook source with a service label, called from your CD pipeline, gives the same result.

Related