How do I pair CloudWatch alarms with logs from Vercel projects for an AI SRE?

Tares pairs CloudWatch alarms with Vercel logs when both sources carry the same primary service label, so a firing alarm sits on one timeline beside the log lines from the same window. CloudWatch reaches Tares through the webhook connector, fed by an EventBridge rule, and Vercel logs arrive through the vercel connector’s log drain. Your agent then reads one correlated timeline per service instead of two separate tools.

How it works

Tares builds one timeline per service when every source is keyed by the same service label, as described in Build an AI SRE. Metrics, logs and alerts are then merged on one clock.

• CloudWatch alarms. Tares has no connector of its own for CloudWatch today. An EventBridge rule on the default event bus matches source aws.cloudwatch and detail-type CloudWatch Alarm State Change. Its target is an API destination that POSTs to the ingest URL of a webhook source. The webhook connector parses the JSON body whatever the Content-Type.
• Vercel logs. A Vercel log drain posts to the ingest URL of a vercel source. Each log entry becomes one event, keyed by the project name taken from the payload’s projectName, else projectId. One drain can carry several projects, and each appears as its own entity.
• The shared key. The Vercel source reads its key from the payload’s project field. You name that label service. On the CloudWatch source you also name a label service and mark it primary.

The two values must be identical. If the Vercel project is web, the CloudWatch events for that project need the service value web.

Set it up

1. Create the Vercel source with Sources → Add source → vercel, or ask a connected agent to create it. Rename the key label to service and keep it primary. It still 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 }

2. Copy the ingest URL from the source page. In Vercel, open Team Settings → Log Drains → Add Log Drain. Set the endpoint to that 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, because Vercel delivers from its cloud.

3. Create the CloudWatch source as a webhook source. If you name each alarm after the Vercel project, detail.alarmName works as a one-level dotted label. Otherwise use one webhook source per service and give it a fixed service value:

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

4. Copy this source’s ingest URL. In EventBridge, create an API destination whose endpoint is that URL (it must be public HTTPS) and whose method is POST.

5. Give the API destination a connection, which EventBridge requires. Use 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.

6. Create a rule on the default event bus that matches source aws.cloudwatch and detail-type CloudWatch Alarm State Change. Set the API destination as its target. If you want the alarm state as a label or in a text template, flatten detail.state.value with an input transformer on the rule target, because it is two levels deep.

7. On a secured instance, also add an ingest-scoped API key to the Vercel drain as a custom Authorization: Bearer header. Each source has its own ingest URL.

8. Check both sources. Recent events shows entries arriving, and Fields shows which service values appear. Open the service in Explore and confirm the alarm and the logs share one timeline.

What you get

• One timeline per service with the CloudWatch alarm event next to the Vercel log lines from the same window.
• An agent that reads the alarm and the logs in one correlated read, over MCP or from a trigger firing, and does not have to query two systems.
• Alarm events stored lossless, so the full EventBridge payload stays available even for fields you did not turn into labels.
• Vercel entries that carry environment (production or preview) and source (lambda, build, edge and others), so you can slice a noisy project.
• A trigger on the alarm source, keyed by service, that wakes an agent with the matching log lines already on the timeline. Build an AI SRE shows the trigger and agent wiring.

When something else fits

• If your alarm actions publish to SNS, this route does not fit. An SNS HTTPS subscription cannot send a custom header, and its SubscriptionConfirmation message would never be confirmed. Use an EventBridge rule instead.
• If the alarm name does not match the Vercel project name, use one webhook source per service with a fixed service value, as in step 3.
• If your logs live outside Vercel, pick the connector that matches where they live and keep the same service key.

Related