Vercel Observability: Keeping Logs and Traces for Months and Tracing into your APIs

Your app runs on Vercel, and for what's happening right now, Vercel's logs and traces are enough. But Vercel keeps traces for a day and logs for 30 days at most, and both stop where your code calls something outside Vercel: the API, the database or the AI model that actually made the request slow. So when a customer reports last week's failed checkout, or your AI agent turns slow, as the one in this guide did when calls to its API averaged about 250 ms instead of 22, Vercel alone can't tell you why, or whether it will happen again.

The fix is standard, Vercel's drains plus OpenTelemetry, but most setups stop at the log drain, and the details that join both sides into one trace, or keep the drain bill from doubling, are easy to miss. This guide walks through the four steps for a Next.js app and an AI agent with a backend on AWS, with the configuration, the cost and the traps. At the end, you keep every request for as long as you need it, follow it from Vercel into your own services, and get an alert before your customers notice.

Both have the same fix: send the data to an observability tool that keeps it longer and also receives data from your other services, in four steps:

1. Drains: Vercel's built-in way to export data. A drain forwards request logs, build logs, firewall decisions and Vercel's own traces to your observability tool as they happen.

2. OpenTelemetry in your code: OpenTelemetry is the open standard for traces, logs and metrics. With it, your code reports what only your code knows, such as database queries, calls to other services and AI model calls.

3. Trace context on outgoing calls: a traceparent header on every call your code makes to a service outside Vercel. It tells that service which request the call belongs to, so its data joins the same trace: the timeline of the request, made up of steps called spans.

4. Deployment events: a webhook that tells your observability tool when a new version went live, so you can connect a problem to the release that caused it.

At the end are the signals worth alerting on and a recommended setup for each type of project.

The guide uses Bronto as the example observability tool, but almost everything in it is standard Vercel drains and standard OpenTelemetry, so it works the same with any tool that supports them. The Bronto-specific setup, such as the Marketplace integration and the ready-made Vercel dashboards, is covered in more detail in the Bronto documentation. The last section shows what this setup looks like with Bronto.

In short: For an online shop or SaaS with up to 100 million requests a month, this setup costs about $11 to $100 a month with Bronto, Vercel's fees included, and the first step takes a few minutes with the Marketplace integration.

Vercel's built-in observability, and when you need more

Vercel's built-in tools are good at what they're made for: while you build and right after a deploy, the Logs page, traces and the Observability charts show what just happened. Observability Plus, Vercel's paid add-on, extends logs and metrics to 30 days and adds queries and anomaly alerts; on teams created or upgraded to Pro on or after 3 April 2026, it's on by default. Once customers depend on your app, you need what Vercel can't give you: history beyond 30 days, the services outside Vercel, and all of it in one place for alerts, dashboards and the questions you or your AI assistant ask during an incident. That takes an observability tool, and it needs to accept OpenTelemetry, because your own spans and the trace context across services rely on it.

What it costs

You pay Vercel's drain fee of $0.50 per GB, the same for every tool, plus the tool itself. Per month, drain fee included:

The volumes assume about 1.5 log lines of 1.2 KB per request on average, for the log drain only. With Bronto, a growing SaaS keeps a year of logs for $19 a month; Observability Plus charges $12 to $72 for 30 days, depending on how many events each request creates. Datadog's price is for 15 days of indexed logs on an annual contract (Flex Logs keep 3 to 15 months, billed per million events for each month stored), and Observability Plus counts 1 to 6 events per request to a function: 1 with Flat Rate CDN, which covers the CDN request's event, more with middleware, outgoing calls and AI Gateway requests. A detailed comparison of tools follows in a separate guide.

The example: a booking assistant for a vet clinic

To show what each step adds, this guide uses one example throughout: the PetClinic agent, an AI assistant on Vercel that pet owners chat with to find a vet and book a visit. It's built with eve, Vercel's framework for AI agents, and Next.js, and it calls the API of Spring PetClinic, a Java app with a Postgres database that runs on AWS, outside Vercel. So it has both gaps from the beginning of this guide: Vercel keeps its traces for a day, and it can't see inside the clinic's API.

The diagram shows the PetClinic agent and where each of this guide's four steps sends data to the observability tool: (1) drains, (2) OpenTelemetry from the code, (3) trace context on the calls to AWS, (4) the deployment webhook.

Vercel                                       AWS
┌───────────────────────────┐                ┌──────────────────────────┐
│ Next.js chat page         │                │ Caddy                    │
│ eve agent with its tools ─┼── HTTP with ──▶│ PetClinic API (Java)     │
│                           │  traceparent   │ Postgres                 │
│                           │      (3)       │ OpenTelemetry Collector  │
└─────┬──────────────┬──────┘                └─────────────┬────────────┘
      │ drains (1)   │ OTLP (2)                            │ OTLP
      │ webhook (4)  │                                     │
      ▼              ▼                                     ▼
┌───────────────────────── observability tool ──────────────────────────┐
└───────────────────────────────────────────────────────────────────────┘

Here is what observability is for. At one point, every answer of the assistant took longer than it should have: calls to the clinic's API averaged about 250 ms. A trace showed where the time went: almost all of it was the trip to the API, not the work inside it. The log drain showed why: the agent's functions ran in Washington, the clinic's API in Ireland. After moving the functions to Dublin, the average dropped to 22 ms. The video walks through that incident in Bronto, with the original data from that day:

Each of the four steps below adds one part of what you see in it.

1. Send Vercel's data out with drains

A drain forwards Vercel's data for one or more projects to your observability tool as it happens, usually within a minute. Drains need a Pro or Enterprise plan. The quickest way to set them up is your tool's Vercel Marketplace integration, which creates them for all projects at once; the dashboard and the REST API work too.

The log drain is the foundation. Every record names its deployment; request records add the environment, region, status code and cache state, and function logs from traced requests carry the trace ID. Most alerts are built on it.

Send everything, once

Vercel bills drains at $0.50 per GB of uncompressed JSON, about $1 per million requests for the log drain. The trace drain is much bigger: in our example app, the PetClinic agent, it was 95% of the drain volume. Part of the reason is easy to miss: the trace drain also forwards the spans your own code creates, so if your code exports them directly as well (step 2), they arrive twice: in our example app, every span we sampled came in through both paths. Send your own spans one way, and you save the duplicates' fee without losing a span.

Everything else is worth keeping, because the request you didn't keep is the one you need when a customer asks about last month. Drain filters are for routing, for example to send the firewall logs to a security team's dataset as well. The drains page in the Bronto docs covers filters, formats and failed deliveries.

2. Add your own spans with OpenTelemetry

Drains carry Vercel's view of a request. Which queries your code ran and which services it called has to come from the code itself, with OpenTelemetry. That costs no drain fee, only a little function time.

In Next.js, @vercel/otel sets it up in one file, instrumentation.ts:

import { registerOTel } from "@vercel/otel";

export function register() {
  registerOTel({
    serviceName: "my-app",
    instrumentationConfig: {
      // Services outside Vercel that should continue the trace (step 3)
      fetch: { propagateContextUrls: ["https://api.example.com"] },
    },
  });
}

Then set OTEL_EXPORTER_OTLP_ENDPOINT to your tool's OTLP endpoint (OTLP is OpenTelemetry's protocol) and OTEL_EXPORTER_OTLP_HEADERS to its API key header, for example x-bronto-api-key=<your key>, in the project's environment variables. For database queries, add the OpenTelemetry instrumentation of your driver or ORM, such as pg or Prisma, to registerOTel's instrumentations, and keep "auto" in the list: instrumentations: ["auto", new PgInstrumentation()]. Without it, the list replaces the default fetch instrumentation, and propagateContextUrls with it. Version 0.76 of @opentelemetry/instrumentation-pg matches @vercel/otel 2.

AI agents get their spans from the framework: agent turns, model calls and tool calls, with the model, tokens and tool names as attributes. With the Vercel AI SDK 7, add @ai-sdk/otel and call registerTelemetry(new OpenTelemetry()) once in instrumentation.ts, next to registerOTel; every Vercel AI SDK call is then traced. With eve, Vercel's framework for AI agents, add OpenTelemetry's OTLP exporter, pinned to version 0.223, because a plain install now gets OpenTelemetry JS 3.x, which @vercel/otel 2 doesn't support. It reads the same two variables:

import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-proto";
import { otelIntegration } from "eve/instrumentation/otel";

export default otelIntegration({ traceExporter: new OTLPTraceExporter() });

If your agent calls its models through the AI Gateway, the AI Gateway trace drain adds what only the gateway knows, including the cost of each model request: in our example app, 3,987 requests in one day cost $0.65.

3. Follow requests into services outside Vercel

When your code calls a service outside Vercel, Vercel's trace shows one fetch span and nothing inside it. To see the whole request, both sides send their spans to the same observability tool, and every call carries the W3C traceparent header, so the service joins the caller's trace.

On the Vercel side, @vercel/otel adds the header for the URLs in propagateContextUrls (step 2). In an eve agent, the undici instrumentation (version 0.33, for the same reason) adds it to every fetch your tools make and records a client span:

import { UndiciInstrumentation } from "@opentelemetry/instrumentation-undici";
import { otel } from "eve/instrumentation/otel";

export default otel({
  instrumentations: [new UndiciInstrumentation()],
});

On the other side, OpenTelemetry continues the trace: the Java agent without code changes, otelhttp in Go, once the W3C propagator is registered (otel.SetTextMapPropagator(propagation.TraceContext{})), and the OpenTelemetry registry lists the instrumentation for other languages and libraries.

In our example app, the PetClinic agent, the slow answers came from functions in Washington calling an API in Ireland. With the functions moved to Dublin (regions: ["dub1"]), one trace runs from the agent's tool call down to the SQL statement:

execute_tool find_owner            13 ms  Vercel
  GET (HTTP client span)         10.8 ms  Vercel
    caddy                        4.74 ms  AWS (proxy)
      GET /petclinic/api/owners  4.35 ms  AWS (Java service)
        …
          select owners pets …    469 µs  AWS (Postgres)

If the service's spans show up in a separate trace instead, its incoming request most likely didn't carry traceparent.

4. Connect problems to deployments

"Did this start with a deploy?" is often the first question in an incident. With deployment events in your observability tool, the answer is a marker on every chart. No drain carries these events or the commit behind them; Vercel pushes them only through webhooks. Webhooks can't send the API key header most tools need, so a small route in your app receives them, checks Vercel's signature and writes each event with the OpenTelemetry Logs SDK. The webhooks page in the Bronto docs has the code.

Alert on what matters

With logs, traces and deployment events in one place, these are the signals worth an alert:

• functions that fail, crash or time out

• more 5xx responses after a deploy

• failed builds

• firewall blocks and rate limits

• slower Web Vitals

• a drain that stops delivering

In Bronto, you don't have to build these from scratch. The Vercel templates attach to the drain data as it arrives: dashboards for traffic, errors, cache, firewall and builds, for Web Vitals and for Web Analytics, and monitors for function errors and timeouts, crashes, 5xx and 4xx spikes, firewall denies, and LCP and INP regressions. Adjust the thresholds to your traffic, and add a "no data in 15 minutes" alert for each drain.

What each step costs on the Vercel side

On top of the observability tool, Vercel charges for the drains and for the function time your exports take. On the Pro plan:

Vercel's billing API shows these per project and day. For our example app, a day with about 14,400 conversations came to $17.73 of Vercel usage, most of it covered by the Pro plan's included usage.

Recommended setup by project type

Where Bronto fits

In Bronto, the Vercel Marketplace integration creates the log, trace, Web Analytics and Speed Insights drains for every project in a team in one step, together with the API key. The Vercel templates add ready-made dashboards and monitors. Your own spans and the telemetry of your other services go to the same OTLP endpoint, so both sides of a request end up in one trace view. Every plan keeps all data hot, meaning searchable right away without restoring it, for 12 months, without sampling. The Starter plan is $10 a month and includes 1 TB, Pro is $500 a month with 5 TB, and Enterprise has custom pricing at $0.10 per GB ingested. For scale: our example app, the PetClinic agent, including the clinic's API and database, sent about 10 GB on its busiest day, so a month at that rate fits the Starter plan three times over.

The Vercel pages in the Bronto docs walk through each method step by step. To try it, install Bronto from the Vercel Marketplace and use it free for 14 days. Moving from Datadog or another tool? Talk to us.

Frequently asked questions

Which observability tool should I use for Vercel? Any tool that accepts Vercel's drains and OpenTelemetry. Compare how long it keeps data, what it charges per GB, and whether it can hold the data of your other services too. Bronto, for example, keeps everything hot for 12 months on every plan.

What does it cost to send Vercel logs to another tool? On Vercel Pro, Vercel charges $0.50 per GB drained (October 2026), about $1 per million requests at one or two log lines each, and the tool comes on top. With Bronto, the total is about $11 a month for a million requests and $19 for ten million, Vercel's fee included.

Observability Plus or a drain? Observability Plus is simpler, and cheaper for a small site, with 30 days of logs inside Vercel. A drain to an observability tool keeps data longer (12 months with Bronto), includes your services outside Vercel and, with Bronto, costs about the same or less from a few million requests a month: $19 a month vs $12 to $72 for Observability Plus at ten million requests (October 2026 prices).

How long does Vercel keep logs and traces? One hour on Hobby, one day on Pro, three days on Enterprise for runtime logs and traces (Vercel's limits). Observability Plus, on by default for teams created or upgraded to Pro on or after 3 April 2026, extends runtime logs and metrics to 30 days (14 days per query); traces stay at the plan's limit, and build logs are kept.

Can Vercel receive telemetry from services outside Vercel? No. Send both sides to an observability tool and connect them with traceparent.

Does gzip compression lower the cost of a drain? No. Vercel bills the uncompressed JSON size of each record, whatever the encoding.

Do I need a trace drain if I export OpenTelemetry from my code? Only if you want Vercel's spans for routing, middleware and the function invocation. The trace drain also forwards your own spans, so if you export them directly too, they arrive twice. Choose one path.

Why are my Vercel functions running in iad1? That's Vercel's default region; set regions to move them next to your data. In a project with services (beta), set it in each service's functions configuration, and check executionRegion in the log drain: in our project, the top-level setting didn't reach the functions, and an eve agent's build output needed the region set after the build.

How do I get deployment events into my observability tool? With a Vercel webhook and a small forwarder that verifies the x-vercel-signature header (HMAC-SHA1 of the body) and sends each event on as a log record. Drains carry build logs, but not deployment events such as created, promoted or rollback.

How do I alert on a failed Vercel build? Use the deployment.error webhook event, or match build logs that contain Build error occurred; in our tests, failed builds reached the drain at level: info, not level: error.

What goes in OTEL_EXPORTER_OTLP_HEADERS on Vercel? Comma-separated key=value pairs, for example x-bronto-api-key=<your key>. Values are percent-decoded, so encode a comma, semicolon or % inside a value; an =, such as at the end of an API key, can stay as it is. Set it next to OTEL_EXPORTER_OTLP_ENDPOINT in the project's environment variables, for Production and Preview. @vercel/otel and OpenTelemetry's OTLP exporters read both.

How do I see what each AI model request costs? Add an AI Gateway trace drain; every trace carries the cost in vercel.ai_gateway.cost.total.

Sample code

The PetClinic agent is open source: bronto-community/petclinic-agent has the eve agent and the Next.js app for Vercel, and the clinic's side (Spring PetClinic, Postgres, Caddy and an OpenTelemetry Collector) as a Docker Compose stack for any host. It works with any observability tool that supports OpenTelemetry.