What should I look for in logs from Vercel projects when the problem is slow database queries?

Tares turns each Vercel log entry into an event on the timeline of the service named by the project, so you can look at the lines that point to slow queries. Start with entries from the lambda source, grouped by path and deployment, and compare counts before and after the slowdown. An agent given that window of logs can summarise how the counts changed instead of reading every raw line.

How it works

A Vercel log drain posts JSON to the ingest URL of a vercel source in Tares. Each log entry becomes one event. The source reads these fields from every entry:

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

The setup below maps project to a service label and marks it primary. Any other source you give the same service value, such as metrics or alerts, lands on the same timeline for that service, next to the logs. See Use AI to monitor your systems for how sources merge into one timeline.

For slow database queries, these are the lines worth looking at:

• Lambda entries first. Filter on source equal to lambda. Server-side functions are where your code waits on the database. Build, static and redirect entries rarely matter for this symptom.
• Paths that repeat. Look at path and see which routes show up more often in the window, or show up with errors in the line text.
• Timeout and connection wording. Look in the line text for whatever your application logs when a query is slow or a connection pool is exhausted, such as timeouts or query durations. What the text says depends on what your code logs, so add a log line on slow queries if you have none.
• A change in deployment or branch. If the odd lines start with one deployment, the slowdown likely came with that change. Most real root causes are a change.
• The environment split. Compare production with preview to see whether only one of them is slow.

An agent works best from counts. Give it a window and ask it to compare the number of lambda entries per path and per deployment before and after the slowdown began. It then reports which paths grew and which deployment they came from, instead of you scrolling raw lines. This follows the pattern in Build an AI SRE: the agent starts from the correlated timeline already in front of it, ties the problem to evidence lines and names a next action.

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. In the console go to Sources, Add source, vercel. You can also ask a connected agent: “Use tares to create a vercel source and give me the ingest URL for the log drain.” The source takes no connector-specific config, only labels. This one maps the Vercel project to the service label so the logs join the service timeline:

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

3. Copy the ingest endpoint from the source page. It is a stable URL of the form shown here:

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

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, which Tares echoes back.
5. If Tares has auth on, add an Authorization header with a Bearer value holding an ingest-scoped API key to the drain as a custom header. Without auth it is not needed.
6. Check the drain. Recent events shows entries arriving, and Fields shows which service values appear and each field’s coverage. If service reads sparse, pick a denser field as the key, or slice by source or environment.
7. Connect an MCP client with tares mcp, then ask for a window, for example: “Use tares: what happened to my service in the last 15 minutes? Compare lambda entry counts per path and per deployment with the 15 minutes before.”

The full connector reference is on the Vercel logs page.

What you get

• One event per Vercel log entry, labeled by service, environment and source, with path, host, deployment and branch available to slice by.
• Logs from several Vercel projects through a single drain, shown as distinct services.
• Vercel logs on the same timeline as your other sources for that service, so a slow path sits next to the alert or deploy that goes with it.
• An agent that answers with a change in counts per path or deployment and points at evidence lines, rather than a wall of raw log text.
• Findings the agent writes back to the timeline, so the next investigation starts from the last conclusion.

When something else fits

• If the database itself is the suspect, add a metrics or Postgres source for it. Vercel logs show what your functions experienced, not what the database did internally.
• If your slow-query lines never reach Vercel logs because your code does not log them, start by adding that logging. Until then the log counts only show symptoms such as errors per path.

Related