How do I cut the noise in logs from Vercel projects before an AI SRE reads them?

Tares cuts Vercel log noise by labeling each entry, filtering with triggers, and handing your AI SRE a window summary instead of raw lines. The vercel connector has only labels to configure, so the filtering happens in triggers on top of those labels. A schedule trigger turns tens of thousands of lines into one readable page of counts per value.

How it works

A Vercel log drain posts to the ingest endpoint of a vercel source in Tares. Each log entry becomes one event, keyed by project, with environment and source as labels. One drain can carry several projects, and each shows up as its own entity. The Vercel connector page covers the full setup.

The connector has no connector-specific fields, only labels. You shape the stream with the labels it provides and with triggers:

• Labels you can slice by: project, environment (production or preview), source (lambda, build, edge, static, external or redirect), path, host, deployment and branch.
• Trigger filters: a condition trigger keeps only events that match its filters, such as production traffic from one source, and fires when the count passes your predicate in a window.
• Window summary: a schedule trigger wakes the agent every interval with a summary instead of raw lines. For each label you name, it gives the count per value in this window against the window before, largest change first, plus a few recent lines.

This is the first level of the pattern in Watch, then escalate. A cheap triage agent reads the summary and says “normal” in a line most of the time. When one entity looks like a problem, it hands that entity to the main agent for root cause. It sits in front of the alert-driven agent described in AI SRE.

Set it up

1. Create the vercel source with the labels you want to slice by. There is no required config.

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

2. In Vercel, open Team Settings, then Log Drains, then Add Log Drain. Set the endpoint to the source’s ingest URL and the delivery format to JSON. The endpoint must be publicly reachable, because Vercel delivers from its cloud. Tares answers Vercel’s x-vercel-verify check for you. The sender uses a Bearer Authorization header holding an ingest-scoped API key, needed only when Tares has auth on. Add it to the drain as a custom header.

3. Open the source and check 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.

4. Add a schedule trigger that summarizes by the labels that matter. A busy drain becomes a page the model can read.

triggers:
  - name: watch-web
    sources: [web-logs]
    key_field: project
    condition:
      every: 10m                       # at least 1m
      summary_by: [environment, source]  # labels to count

5. If you also want a trigger that ignores everything except one slice, add filters and a count condition. This one looks only at production lambda and edge logs.

triggers:
  - name: prod-burst
    sources: [web-logs]
    key_field: project
    filters:
      - { field: environment, op: eq, value: production }
      - { field: source, op: in, value: [lambda, edge] }
    condition: { aggregate: count, predicate: "> 50", window: 5m }
    cooldown: 30m

6. Create a Tares agent on watch-web and seed its prompt from the Triage (on a schedule) preset. Pick the cheapest model that calls tools reliably and set a budget. The preset considers only values that grew at least 3x and by at least 50 events since the window before, and it ignores routine noise such as uptime probes. Edit the prompt to tune those numbers.

7. Raise the daily run limit if you need to. A 10 minute schedule is 144 runs a day, above the default of 50 runs per agent per day. Change it under Settings, Agents or with TARES_AGENT_DAILY_CAP.

What you get

• A short read for the model. The agent sees counts per label value, the change against the previous window and a few recent lines, not every log entry.
• Noise handled where it belongs. Labels decide what you can slice by, trigger filters keep out slices you do not care about, and the triage prompt skips routine traffic.
• Escalation only when something moves. Most triage runs end as “no finding” with a one-line reason. A flagged run records an investigate finding on that entity, and the main agent takes over.
• Predictable cost. A small model reading a summary costs well under a cent a run, and the main agent runs at most once per cooldown per entity.
• Every step on the timeline. Each tick, triage verdict, handoff and root-cause note is recorded on the entity.

When something else fits

• If you need to drop individual log lines before they are stored, the vercel connector cannot do it, because it has only labels. Filter with triggers instead, or reduce what the drain sends from Vercel.
• If you want an agent woken only by a specific condition, such as a burst of production errors, use the condition trigger on its own and skip the schedule summary.
• If your logs come from a source that has match or drop settings, such as a polled log connector, use those settings first and keep the triggers for the rest.

Related