How do I show Vercel deploys beside logs from Docker containers for an AI SRE?

Tares puts Vercel activity and Docker container logs on one timeline when both sources carry the same service label. Create a docker_logs source and a vercel source, give each a primary label named service with the same value, and Tares merges them in time order. Your AI SRE agent can then read one timeline and check whether the first error lines start after the Vercel change.

How it works

Tares builds one timeline per entity, and the entity comes from the primary label of each source. Sources that share a label value land on the same timeline, merged on one clock. This is the same approach the AI SRE guide uses to put metrics, logs and alerts side by side.

Two connectors do the work here:

• The docker_logs connector tails a running container’s logs, one event per line, polled every few seconds. Its primary label is a constant you choose.
• The vercel connector receives a Vercel log drain. Each log entry becomes one event. The entry’s project is the key, and environment, source, path, host, deployment and branch come along as labels. Build output arrives with source set to build.

The Vercel source takes its key from project by default. To line it up with your containers, name the primary label service and read it from the project field. Then make the const on the Docker source equal to the Vercel project name. The same service value on both sides is what joins them.

The agent does the comparison. It reads the merged timeline, finds the Vercel entries for the new deployment or branch, and checks whether the first error lines in the container logs come after them.

Set it up

1. Make sure Tares can reach what it needs. For Docker, run taresd on the host, or mount the Docker socket and include the Docker CLI in the image. For Vercel, the ingest endpoint must be publicly reachable, because Vercel delivers from its cloud. Use a deployed instance or a tunnel, since a bare localhost daemon does not receive drains.

2. Add the Docker logs source. Set container to the name from docker ps, and give it a primary service label with a constant value. If the container runs under Compose, set compose_file so the tail follows restarts.

- name: logs
  connector: docker_logs
  poll: 5s
  config:
    container: tares-demo-api-server   # the container name (docker ps)
    labels:
      - { name: service, const: api-server, primary: true }

3. Add the Vercel source. There is no required config. Rename the key label to service and read it from project, so it matches the Docker source. In this example, the Vercel project is also called api-server.

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

4. Copy the source’s ingest endpoint from its page. It is a stable URL of the form shown below.

https://<host>/ingest/<ingest_key>

5. In Vercel, open Team Settings, then Log Drains, then Add Log Drain. Set the endpoint to the ingest URL and the delivery format to JSON. Vercel verifies the endpoint with an x-vercel-verify header, and Tares echoes it back. The drain sends a Bearer Authorization header holding an ingest-scoped API key, needed only when Tares has auth on.

6. Verify both sides. Open each source in the console and check Recent events. Then open Explore, pick the api-server service, and confirm Vercel entries and container lines appear together in time order.

You can also ask a connected agent to do the setup, for example: use tares to create a vercel source and give me the ingest URL for the log drain.

What you get

• One timeline for the service, with Vercel entries and container log lines in time order.
• Vercel labels such as deployment, branch and environment beside the log lines, so the agent can tell which change it is looking at.
• A way to answer “did the errors start after the change?” from a single read, instead of querying two systems.
• The same timeline for any trigger-woken agent or any MCP client you connect, so the comparison works whether the agent is woken automatically or you ask it yourself.

A single Vercel drain can carry several projects. Each appears as its own entity, so you can point the service label at as many matching Docker sources as you have projects.

When something else fits

• If you need a deploy event that reads as one line per release, send it from your CD pipeline to a webhook source with the same service label, as the AI SRE guide shows. A Vercel log drain carries log entries, not one summary event per deploy.
• If your Tares runs on a laptop with no public URL, put a tunnel or a deployed instance in front of it before adding the drain.
• If project reads sparse in the Fields view, pick a denser field as the key, or slice by source or environment.

Related