Vercel Datadog Log Drain: Ship Deployment Logs (2026)

Datadog log drains in Vercel are more about what you’re sending than how you’re sending it, and the real magic is in how Datadog indexes and correlates those Vercel deployment events with your application’s runtime logs.

Let’s see this in action. Imagine a Vercel deployment goes sideways. You’ve got a vercel.json that looks something like this:

{
  "githubToken": "your-github-token",
  "outputDirectory": "dist",
  "routes": [
    { "src": "/(.*)", "dest": "/index.html" }
  ],
  "functions": {
    "api/hello.js": {
      "runtime": "nodejs18.x"
    }
  },
  "logDrain": {
    "url": "https://http-intake.logs.datadoghq.com/api/v2/logs?dd-api-key=YOUR_DD_API_KEY&dd-site=your-datadog-site"
  }
}

And a simple api/hello.js function:

export default function handler(request, response) {
  if (Math.random() > 0.5) {
    response.status(500).send("Internal Server Error: Random failure!");
  } else {
    response.status(200).json({ message: "Hello from Vercel!" });
  }
}

When you deploy this, Vercel will send build logs, deployment events (like "New deployment created," "Deployment successful," "Deployment failed"), and importantly, any logs generated by your serverless functions to the Datadog URL specified in logDrain.

The problem Vercel log drains solve is log aggregation for your serverless functions without needing to instrument your code with a Datadog agent. Vercel handles the ingestion of the function’s stdout/stderr and the deployment metadata, and the logDrain simply forwards this to your configured endpoint. In Datadog, you’d then see logs tagged with service:vercel, deployment_id:your-deployment-id, and environment:your-env. If your api/hello.js function throws that random error, the 500 status and the "Internal Server Error: Random failure!" message will appear in Datadog, correlated with the specific deployment that produced it.

The internal mechanism is straightforward: Vercel’s deployment platform captures stdout and stderr from your function executions, along with key deployment lifecycle events. When a logDrain is configured, Vercel constructs a payload containing these logs and events and makes an HTTP POST request to the specified url. This payload is typically JSON, and Datadog’s HTTP intake API is designed to parse and index this data. The crucial part is that Vercel adds context – like the deployment ID and function name – to these logs before they are sent. This context is what allows Datadog to link a function error back to a specific Vercel deployment, which is invaluable for debugging.

The exact levers you control are the url and the data you send to that URL. Vercel’s default behavior is to send standard output, standard error, and deployment events. You can’t directly control the format of the Vercel-generated logs themselves via the logDrain config, but you can influence what appears in Datadog by:

1. Adding Custom Log Messages: Within your serverless functions, use console.log() or console.error() to output structured JSON or plain text messages that include relevant context. For example:

   console.log(JSON.stringify({
     level: 'info',
     message: 'Processing user request',
     userId: request.headers['x-user-id'] || 'anonymous'
   }));
   

   Vercel will capture these and send them to Datadog.

2. Leveraging Environment Variables: Use Vercel’s environment variables to inject configuration or context into your logs.

   console.log(`Processing request for project: ${process.env.VERCEL_PROJECT_NAME}`);
   

3. Datadog Log Processing Rules: Once logs are in Datadog, you can use their parsing and processing rules to extract and re-index fields from the raw log message, especially if you’re sending structured JSON. This allows you to create facets and metrics from your Vercel logs.

The most surprising thing most people miss is that Vercel’s logDrain doesn’t just forward function logs; it also sends critical deployment metadata. This means you can query Datadog for all logs associated with a failed deployment or all logs from a specific version of your application, without any extra code changes in your functions. The deployment_id tag is your golden key here, linking runtime errors directly to the build and deployment artifacts.

The next concept you’ll likely encounter is setting up Datadog monitors based on these Vercel logs to proactively alert you to deployment failures or error spikes.