How do I label Vercel logs by service so they join the right timeline?

Tares joins Vercel logs to a service’s timeline when the log source declares a label named like the service label on your metrics and alerts, and marks it primary. In the vercel source, add { name: service, field: project, primary: true }, or use const for a drain that carries one project. Logs then share a key with the service’s metrics and alerts and appear on the same timeline.

How it works

Tares builds one timeline per service from every source that carries the same primary label. The AI SRE guide keys its metrics, logs and alerts sources by a service label, and Explore then shows them merged on one clock.

The Vercel connector is a push source. You point a Vercel log drain (JSON) at the source’s ingest endpoint, and each log entry becomes one event. By default the source is keyed by project, which comes from the payload’s projectName, else projectId. It also pre-fills environment and source as labels.

A label has a name, and a value that comes from either a payload field or a const. One label is marked primary, and that one is the key. To join a service’s timeline, declare a label with the same name your other sources use, and mark it primary:

• Use field: project when one drain carries several Vercel projects. Each project stays a distinct entity and gets its own service value.
• Use const when the drain carries a single project and you want to set the service name yourself.

The value must match what your metrics and alerts sources put in their service label. Matching names are what put the entries on one timeline.

Set it up

1. Check the service label on your other sources. If your Prometheus metrics and alerts sources use a label named service, use that name for the Vercel logs too.
2. In the console, go to Sources → Add source → vercel. You can also ask a connected agent to create a vercel source and give you the ingest URL.
3. Declare the service label and mark it primary. This example reads it from the project field and keeps environment and source as extra labels:

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

4. If the drain carries one project and its name differs from your service name, use a constant instead of a field:

- name: web-logs
  connector: vercel
  config:
    labels:
      - { name: service, const: api-server, primary: true }
      - { name: environment, field: environment }

5. Save the source and copy its ingest endpoint. The 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.
6. 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 the x-vercel-verify header back during Vercel’s verification.
7. If Tares has auth on, add a custom header to the drain: an Authorization Bearer header holding an ingest-scoped API key. It is needed only when Tares has auth on.
8. Check the result. Recent events shows entries arriving, and Fields shows which values appear and each field’s coverage. Then open Explore and pick the service to see the logs next to its metrics and alerts.

What you get

• Each Vercel log entry lands on the timeline of the service it belongs to, merged on one clock with that service’s metrics and alerts.
• A drain that carries several projects splits into one entity per project, so each project can map to its own service.
• The environment label (production or preview) and the source label (lambda, build, edge, static, external or redirect) stay available for slicing.
• Triggers and agents that key on the service label read the Vercel logs as part of the same correlated timeline.

When something else fits

• If Fields shows the label you chose is sparse, pick a denser field as the key, or slice by source or environment.
• If your logs come from containers or an OpenTelemetry pipeline rather than a Vercel drain, use the docker_logs or OTLP connectors. The labeling idea is the same: declare the shared label and mark it primary.

Related