How to add Datadog logging to a Webflow Cloud app that already uses Sentry

Webflow Cloud runs your app as a Cloudflare Worker, so when a Route Handler throws an uncaught exception, the request returns a 500 and leaves nothing behind that you can read afterward. Error tracking and structured logging close that gap, giving you both the stack trace for what broke and a record of what the app was doing right before it did.

The setup is two tools with two different jobs: Sentry catches exceptions and surfaces stack traces when something breaks, and Datadog receives structured logs from your Route Handlers for continuous operational visibility. Together, they cover the gap between "something is wrong" and "here is exactly what happened."

One note before we start. Webflow Cloud runs your app on Cloudflare Workers, and Datadog's dd-trace APM SDK does not run there because it depends on Node.js async_hooks. The fix is Datadog's HTTP log intake API, a plain fetch call that runs cleanly on Workers. That's what this guide uses.

What do you need for error tracking and monitoring in Webflow Cloud?

You need a Webflow Cloud Next.js app, a Sentry account, and a Datadog account. Both offer free tiers that cover development and low-traffic production use.

Here’s what you need:

• A Webflow Cloud project running a Next.js app
• A Sentry account with a Next.js project (sentry.io/signup)
• A Datadog account with an API key (app.datadoghq.com)
• Node.js 22 or higher locally

The Sentry setup uses Sentry's official Next.js wizard and takes about 5 minutes. Webflow Cloud already enables Node.js compatibility for your Worker by default, which is what the Sentry SDK needs to run. The Datadog setup is a single utility file and a few log calls in your Route Handlers.

4 steps to add Datadog logging to a Webflow Cloud app that already runs Sentry

Sentry and Datadog cover different layers of observability. Sentry captures unhandled exceptions with full stack traces, user context, and request metadata; it answers "what broke and why." Datadog receives structured logs you emit deliberately from Route Handlers; it answers "what is the app doing right now." I run both on every Webflow Cloud project because they're complementary, not redundant.

Let’s go into the steps.

1. Point your existing Sentry setup at Webflow Cloud

This guide assumes Sentry is already reporting from your app. If it is not, our guide to adding Sentry error tracking to a Webflow Cloud app walks through creating the project, running npx @sentry/wizard@latest -i nextjs, and adding the DSN as an environment variable, for both Next.js and Astro. Rather than repeat that here, this guide starts where it ends and adds the second half of the picture.

There is one Webflow Cloud detail worth confirming before you move on, because it decides which Sentry config actually runs. Webflow Cloud deploys Next.js through the OpenNext Cloudflare adapter, which runs your Route Handlers on the Next.js Node.js runtime rather than the Next.js Edge runtime. So sentry.server.config.ts is the file that loads for your API routes, and the instrumentation.ts the wizard generated already selects it based on the runtime. You do not need to change anything, but the file should look like this:

// sentry.server.config.ts
import * as Sentry from '@sentry/nextjs'

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: process.env.NODE_ENV === 'development' ? 1.0 : 0.1,
  enableLogs: true,
})

2. Get a Datadog API key

Log in to app.datadoghq.com.

Go to Organization Settings > API Keys > New Key. Name it something like webflow-cloud-prod. Copy the key.

Add it to .env.local and Webflow Cloud's environment variables:

DD_API_KEY=your_datadog_api_key_here
DD_SITE=datadoghq.com

DD_SITE controls which regional endpoint to use (datadoghq.com for US1, datadoghq.eu for EU). Do not add NEXT_PUBLIC_. This key must stay server-side.

3. Build a Datadog logger utility for Webflow Cloud Route Handlers

The dd-trace APM SDK requires Node.js.

For Webflow Cloud's edge runtime, use Datadog's HTTP log intake API directly. Create a lib/logger.ts utility:

// lib/logger.ts

type LogLevel = 'info' | 'warn' | 'error' | 'debug'

type LogEntry = {
  level: LogLevel
  message: string
  service?: string
  [key: string]: unknown
}

const DD_INTAKE = `https://http-intake.logs.${process.env.DD_SITE ?? 'datadoghq.com'}/api/v2/logs`

async function sendLog(entry: LogEntry): Promise<void> {
  const payload = [
    {
      ddsource: 'nextjs',
      ddtags: `env:${process.env.NODE_ENV},runtime:edge`,
      hostname: 'webflow-cloud',
      service: entry.service ?? 'webflow-app',
      level: entry.level,
      message: entry.message,
      // Spread the rest of the fields as structured metadata.
      ...Object.fromEntries(
        Object.entries(entry).filter(([k]) => !['level', 'message', 'service'].includes(k))
      ),
    },
  ]

  await fetch(DD_INTAKE, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'DD-API-KEY': process.env.DD_API_KEY!,
    },
    body: JSON.stringify(payload),
  })
}

// Fire-and-forget wrappers; do not await in the request path.
export const logger = {
  info: (message: string, meta?: Record<string, unknown>) =>
    void sendLog({ level: 'info', message, ...meta }),
  warn: (message: string, meta?: Record<string, unknown>) =>
    void sendLog({ level: 'warn', message, ...meta }),
  error: (message: string, meta?: Record<string, unknown>) =>
    void sendLog({ level: 'error', message, ...meta }),
  debug: (message: string, meta?: Record<string, unknown>) =>
    void sendLog({ level: 'debug', message, ...meta }),
}

The void prefix on each wrapper is intentional. Log calls should never block the response; the fetch to Datadog runs in the background, and any failure is silently dropped.

For mission-critical logs where you need delivery guarantees, await sendLog(...) directly. In my experience, fire-and-forget is the right default for Route Handlers where response latency matters.

4. Add Datadog logging to Webflow Cloud Route Handlers

With the logger utility in place, logging from any Route Handler is one import away:

// app/api/orders/route.ts
import { logger } from '@/lib/logger'
import { NextResponse, type NextRequest } from 'next/server'

export async function POST(request: NextRequest) {
  const startTime = Date.now()

  try {
    const { orderId, customerId } = await request.json() as {
      orderId: string
      customerId: string
    }

    logger.info('Order processing started', {
      service: 'orders',
      orderId,
      customerId,
    })

    // ... order processing logic

    const duration = Date.now() - startTime
    logger.info('Order processed successfully', {
      service: 'orders',
      orderId,
      duration,
    })

    return NextResponse.json({ ok: true })
  } catch (error) {
    const duration = Date.now() - startTime
    logger.error('Order processing failed', {
      service: 'orders',
      reason: error instanceof Error ? error.message : String(error),
      duration,
    })
    return NextResponse.json({ error: 'Failed to process order' }, { status: 500 })
  }
}

The service field on each log entry groups logs in Datadog's log explorer. Set it consistently to the domain (orders, auth, webhooks), and you can filter by service to isolate problems to a specific part of the app.

What breaks error tracking and monitoring in Webflow Cloud? Tips to troubleshoot

Most Sentry and Datadog problems on Webflow Cloud trace back to one of four things, a missing build-time token, a missing instrumentation export, a hardcoded service name, or a region mismatch. Each one fails quietly, so the symptom rarely points straight at the cause.

Here is how to recognize each one and what to change.

Sentry errors show minified stack traces without source locations

Source maps aren't being uploaded. Confirm SENTRY_AUTH_TOKEN is set in your Webflow Cloud environment variables and that withSentryConfig wraps your next.config.ts. Source maps are uploaded during build, so a missing auth token causes silent failures at build time rather than runtime errors.

Route Handler errors reach Sentry but show no request context

The export const onRequestError = Sentry.captureRequestError line is missing from instrumentation.ts. Without it, errors captured via the default Next.js error handling don't include request headers or URL. Add the export and redeploy.

Datadog logs arrive, but all appear under the same service name

The service field is hardcoded to 'webflow-app' in the logger utility default. Pass a service key on every log call that identifies the specific Route Handler domain (e.g., service: 'webhooks'). That key overrides the default and shows up as a separate service in Datadog's service map.

Datadog logs are missing from the Log Explorer after sending

Check that DD_SITE matches the Datadog region your account is on. US1 accounts use datadoghq.com; EU accounts use datadoghq.eu. A mismatch sends logs to a different region's intake endpoint, where they're accepted (no error returned) but never appear in your account.

Extend error tracking and monitoring across your Webflow Cloud app

The setup in this guide provides baseline observability: unhandled exceptions in Sentry and structured logs in Datadog. Both extend cleanly from here.

For Sentry, add user context to errors using Sentry.setUser({ id, email }) in your auth middleware or at the start of authenticated Route Handlers. User context turns "500 on /api/checkout" into "these 3 specific users hit a checkout failure between 14:00 and 14:05."

For Datadog, add a correlationId to every log entry generated at the start of each request. Pass the correlation ID through all log calls in a request's lifecycle, and you can reconstruct the full sequence of events for any specific request by filtering @correlationId:abc123 in the Log Explorer.

Explore Webflow + Sentry for the webhook patterns that sync captured Sentry issues into a Webflow CMS error log.

Explore Webflow + Datadog for the real user monitoring and synthetic checks that extend this logging setup to your published Webflow pages.