How does an AI SRE read logs from Vercel projects while investigating a cron job that stopped?

Tares receives your Vercel logs through a log drain pointed at a vercel source, so an agent can read them as events in Tares while it investigates a stopped cron job. Each log entry becomes one event keyed by project, with environment and source as labels. You connect the drain once, check that entries arrive, and then ask a connected agent to look at the window around the alert.

How it works

The vercel connector is a push source. Vercel delivers its log drain (JSON) to the source’s ingest endpoint, a stable URL of the form https://<host>/ingest/<ingest_key>, and Tares turns each log entry into one event.

Every event carries these labels:

• project, the key. It comes from the payload’s projectName, else projectId.
• environment, either production or preview.
• source, one of lambda, build, edge, static, external or redirect.
• path, host, deployment and branch.

A single drain can carry several projects, and each one appears as its own entity. That lets an agent separate the project that owns the cron job from the others on the same drain.

In the AI SRE guide, the demo sources share one label so that Explore merges them on one clock and an agent reads them together. Your Vercel source is keyed by project. The agent works from the evidence Tares holds, and you narrow it by project, environment, source and path.

Set it up

1. Make the ingest endpoint publicly reachable. Vercel delivers from its cloud, so use a deployed instance or a tunnel. A bare localhost daemon does not receive drains.
2. Create the source. Ask a connected agent: “Use tares to create a vercel source and give me the ingest URL for the log drain.” The agent calls create_source, which needs no config, and returns the ingest endpoint. In the console, go to Sources, Add source, vercel. The project, environment and source labels are pre-filled, so you only save.
3. Check the source definition. It has no connector-specific fields, only labels:

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

4. In Vercel, open Team Settings, Log Drains, 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 from Vercel’s verification request.
5. If Tares runs with auth on (tares up --auth), add a custom header to the drain: Authorization: Bearer <key>, where the key is an ingest-scoped API key. Without auth on, you do not need it.
6. Verify. Open Recent events to see entries arriving. Open Fields to see which projects appear and each field’s coverage. If project reads sparse, pick a denser field as the key, or slice by source or environment.
7. Connect your MCP client so an agent can read the evidence. Start the endpoint in a second shell:

tares mcp

8. Ask about the stopped job and give it a window. For example: “Use tares: what did the Vercel logs for this project show around the time the cron job should have last run?” Add the environment, and the path if you know it, to keep the read tight.

What you get

• Vercel log entries in Tares as one event each, with project, environment, source, path, host, deployment and branch as labels.
• Several Vercel projects through one drain, each as a distinct entity, so the agent can keep the cron job’s project apart from the rest.
• A way to narrow the evidence. Filter by environment to separate production from preview, and by source to separate lambda, build, edge, static, external and redirect entries. Use path and deployment to check which route and which deploy an entry came from.
• A quick check on coverage. The Fields view shows which projects arrive and how dense each field is, so you know whether the logs you need are in Tares before you ask the agent.
• An investigation you can repeat. The same connected client can ask the question again after a new deploy or a fix.

When something else fits

If your logs come from containers or an OpenTelemetry pipeline instead of Vercel, use the docker_logs or OTLP connectors, as the AI SRE guide describes. If you need the drain to work from a laptop with no public address, use a tunnel or a deployed instance first, because Vercel cannot reach a bare local daemon.

Related