How do I correlate 5xx errors on an API with Vercel deploys using an AI SRE?

Tares puts your API’s 5xx metrics and your Vercel logs on one per-service timeline, so an AI SRE agent sees the order of events. You create a vercel source whose primary label is service, point a Vercel log drain at its ingest URL, and the deployment and branch of each log entry land beside the 5xx rate and alerts. When a trigger fires, the agent reads that one timeline and can tell whether errors started after a deploy. This is the pattern in Build an AI SRE.

How it works

Most root causes are a change, so Tares correlates by service. Every source that carries the same service label lands on one timeline for that service, on one clock.

• Metrics and alerts for the API come from the prometheus and prometheus_alerts connectors, keyed by service. The 5xx rate and the alert that fired sit on the timeline.
• Vercel logs come from the vercel connector. A Vercel log drain posts one event per log entry. The connector reads project from the payload’s projectName, else projectId, and you map it to the service label.
• Deploy context arrives as labels on each Vercel event: deployment, branch, environment (production or preview), source (lambda, build, edge, static, external or redirect), path and host.
• The agent reads the merged timeline, either woken by a trigger or asked through an MCP client. It sees, for example, a new deployment appear and the 5xx rate climb afterwards.

The service value from Vercel must match the value your metrics and alerts use. If your Prometheus labels call the API api-server, the Vercel project name has to be api-server too, or the events land on a separate timeline.

Set it up

1. Key your 5xx metrics and your alerts on service, using the prometheus and prometheus_alerts connectors, as the AI SRE guide does.
2. Create the Vercel source under Sources → Add source → vercel, or ask a connected agent: “Use tares to create a vercel source and give me the ingest URL for the log drain.” Key it on service by reading the project field:

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

3. Copy the source’s ingest endpoint, a stable URL of the form https://<host>/ingest/<ingest_key>. Vercel delivers from its cloud, so this URL must be publicly reachable. Use a deployed instance or a tunnel, because a bare localhost daemon will not receive drains.
4. 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. When Tares has auth on, add an Authorization Bearer header holding an ingest-scoped API key to the drain as a custom header.
5. Check the source. Recent events shows entries arriving, and Fields shows which projects appear and each field’s coverage. If the project field reads sparse, pick a denser field as the key, or slice by source or environment.
6. Add a trigger over your sources, keyed by service, that fires when the alert event arrives. Subscribe a Tares agent, your own agent over a webhook, or a Slack channel to it.
7. To investigate on demand, start the MCP endpoint with tares mcp, connect your client, and ask: “Use tares: what happened to api-server in the last 15 minutes?”

tares mcp

What you get

• One timeline per service where 5xx metrics, alerts and Vercel log entries appear in order, so “deployment changed, then errors started” is visible in a single read.
• Deploy context on every Vercel event through the deployment, branch, environment and source labels, so you can slice the timeline to production builds or one branch.
• An agent that starts from the correlated evidence instead of querying each system separately, and writes its finding back onto the same timeline for the next investigation.
• Several Vercel projects through one drain. Each project appears as a distinct entity, keyed by its project name.

When something else fits

• If your deploys do not go through a Vercel log drain, such as a pipeline that deploys elsewhere, send one webhook event per deploy from your CD pipeline, keyed on the same service label.
• If your Tares runs only on a laptop with no public URL, Vercel cannot reach it. Use a tunnel or a deployed instance first, or begin with the demo walkthrough in Build an AI SRE.
• For the full Vercel source reference, see the Vercel connector page.

Related