Drain Vercel into Elastic: serverless observability with nothing to install
A drain and an API key put Vercel logs, traces, and Speed Insights into Elastic Cloud, where you can follow a slow request from the edge to the Lambda function behind it.
Elastic speaks OpenTelemetry natively. Send traces, logs, and metrics over OTLP straight into Elasticsearch, no proprietary agents required. See how it fits together, try it for free in the cloud, or run it locally.
Something breaks in production. Your Lambda error rate is climbing, users are bouncing, and you're staring at the Vercel dashboard trying to understand whether this is a code problem, a cold start problem, or something happening in a specific region. The logs tell you something happened. They don't tell you why, where it started, or what the user actually experienced.
This is the gap that Elastic's Vercel Integration is designed to close. Not just logs, but the full picture. Real-user performance, server health, traces showing the complete request journey, governance events, traffic, and engagement. All of it is queryable in one place.
And this is the part that's easy to miss: there's nothing to deploy on your side. No OpenTelemetry Collector, no Elastic Agent, no agent policy. Vercel has a feature called Drains that streams your data as HTTP webhooks. Elastic operates a managed endpoint on Elastic Cloud that receives those payloads and writes them into Elasticsearch. You point a drain at a URL with an API key, and data starts flowing. That's the entirety of the infrastructure story.
What Vercel drains send to Elastic Cloud
The integration pulls in five signal types from Vercel, and they're more complementary than they might seem at first.
| Signal | What it carries | SDK required | Plan | Endpoint |
|---|---|---|---|---|
| Web Analytics | Page views and custom events, with traffic patterns and geography | @vercel/analytics | Pro or Enterprise | Vercel endpoint |
| Speed Insights | Real user Web Vitals: LCP, INP, CLS, TTFB, tagged by route, device type, and country | @vercel/speed-insights | Pro or Enterprise | Vercel endpoint |
| Logs | Build output, static asset requests, Lambda function output, edge function output | None | Pro or Enterprise | Vercel endpoint |
| Audit Logs | Team governance events: environment variable changes, drain edits, project transfers | None | Enterprise | Vercel endpoint |
| Traces | Infrastructure spans and outbound HTTP fetch calls, plus framework and custom spans | @vercel/otel (optional) | Pro or Enterprise | Managed OTLP endpoint, /v1/traces |
Vercel Web Analytics: traffic and custom events
Web Analytics captures page views and custom events from the @vercel/analytics SDK (traffic patterns, geography, what pages users are actually hitting). The SDK itself can be installed on any Vercel plan. Forwarding that data to Elastic requires a drain, which is available on Pro and Enterprise plans.
Vercel Speed Insights: real user Web Vitals
Speed Insights carries real-user Web Vitals, including LCP, INP, CLS, and TTFB. These are measured in the browser and tagged with route, device type, and country. Install the @vercel/speed-insights SDK in your app, then create a drain on a Pro or Enterprise plan to send Web Vitals to Elastic. When you see a Lambda error spike and want to know whether users actually noticed, this data can help answer that question.
Vercel logs: build, Lambda and edge output
Logs cover the full server-side runtime picture, including build output, static asset requests, Lambda function output, and edge function output. When something fails, this is where you start digging. You can configure sampling rates and narrow by environment directly in the Vercel drain settings. Logs require a Pro or Enterprise plan.
Vercel audit logs: team governance events
Audit Logs cover team-level governance events (who changed an environment variable, who modified a drain, and who transferred a project). It is surprisingly useful when you're trying to understand whether a configuration change preceded an incident. Audit Logs require an Enterprise plan.
Vercel traces: OpenTelemetry spans end to end
Traces are where the integration gets genuinely powerful for debugging. When you configure a Trace Drain, Vercel automatically instruments infrastructure spans and outbound HTTP fetch calls. You can add the @vercel/otel package for framework and custom spans. These traces surface in Kibana's Service Inventory: trace waterfalls, service maps, and the ability to jump directly from a trace to the related log lines. A Pro or Enterprise plan is required for traces. Traces use a separate endpoint from the other signals; they go to /v1/traces on the Managed OTLP endpoint.
Each signal has its own drain in Vercel and lands in its own data stream in Elasticsearch.
How to send Vercel logs, speed insights, web analytics and traces to Elastic Cloud
In Elastic Cloud, go to Add data → Connect directly to the endpoint. You'll see the Vercel endpoint listed alongside an option to create an API key. Grab both before heading to Vercel.
The Vercel endpoint URL and API key are both available here; everything you need before touching Vercel's settings.
Over in Vercel, open your team settings and go to Drains → Add Drain. Pick the signal type you want to collect, hit Next, paste in the Elastic endpoint URL, and add one custom header:
Authorization: ApiKey <your-key>
Vercel lets you drain Logs, Traces, Speed Insights, Web Analytics, Audit Logs and more, with each as a separate drain. Logs, Speed Insights, Web Analytics, and Audit Logs share the Vercel endpoint, while Traces use the Managed OTLP traces URL.
The destination URL and Authorization header are all it takes – Elastic handles everything from here.
Repeat for each signal type. For Traces, use the Managed OTLP endpoint with /v1/traces appended, and not the standard Vercel drain URL.
For the full setup walkthrough and configuration options, refer to the Vercel (OpenTelemetry) Integration docs.
Serverless monitoring in Kibana: dashboards, alerts and SLOs
Once data is flowing, all the assets (dashboards, alert and SLO templates) install automatically. But the real value isn't in isolation, it's having everything in the same place when something goes wrong.
Dashboards
The Logs dashboard is where most investigations start: request volume, error rates, HTTP status distribution, top routes, and regional breakdowns. If errors are concentrated in a single region or a specific route, you can spot it right away.
The Speed Insights dashboard shows Core Web Vitals at p75, over time and per page, using the same "good / needs improvement / poor" thresholds Vercel uses. When a deployment ships and LCP starts drifting, this is where you'll see it first.
The Web Analytics dashboard covers the client-side traffic story: page views, geography, devices, top pages, and custom events. It is useful on its own, but especially alongside the Logs dashboard when you're trying to understand whether a server-side problem is actually reaching users.
Ten alert rules for Vercel failure modes
Beyond dashboards, ten pre-built alert rules cover the failure modes that actually matter for Vercel workloads:
- 5xx spikes.
- Lambda and edge function hard crashes (the kind that never return an HTTP response and disappear from standard error-rate math).
- Sudden traffic drops on both server and client side.
- Regional error concentration.
- TTFB degradation as an early warning for LCP regressions.
- WAF deny spikes.
- Suspicious audit activity from a single actor.
Five SLO templates for error rate and Web Vitals
Five SLO templates round things out, all on a rolling 30-day window. Server-side error rate at 99% is the core target. The remaining four cover Core Web Vitals and TTFB at p75, so real-user performance becomes something you can formally commit to, not just a metric you check occasionally.
Trace waterfalls and service maps in Kibana
For traces, once data is flowing you get the full experience in Kibana's Service inventory: end-to-end trace waterfalls, service maps, and log lines correlated right alongside the spans.
Set up serverless observability for your Vercel project
If you're already on Elastic Cloud, you're closer than you think. The endpoint is already there; you just need to point Vercel at it. Start with Web Analytics or Speed Insights if you want a focused first step: install the SDK Vercel already recommends, then create a drain on your Pro or Enterprise team. You'll have real-user performance data in Kibana within minutes. From there, layer in logs, then traces when you're ready for the full debugging story.
The integration is available on Elastic Cloud Serverless and Elastic Cloud Hosted. Head to Add data → Connect directly to the endpoint in your Elastic Cloud project to grab your endpoint URL and get going.




