Cómo añadir registros de Datadog a una aplicación de Webflow Cloud que ya utiliza Sentry

Webflow Cloud ejecuta tu aplicación como un Cloudflare Worker, por lo que cuando un Route Handler lanza una excepción no controlada, la solicitud devuelve un error 500 y no deja nada que puedas leer después. El seguimiento de errores y el registro estructurado cierran esa brecha, proporcionándote tanto el seguimiento de la pila de lo que falló como un registro de lo que la aplicación estaba haciendo justo antes de que ocurriera.

La configuración consta de dos herramientas con dos funciones diferentes: Sentry captura excepciones y muestra seguimientos de pila cuando algo falla, y Datadog recibe registros estructurados de tus Route Handlers para una visibilidad operativa continua. Juntos, cubren el vacío entre "algo va mal" y "esto es exactamente lo que ha pasado".

Una nota antes de empezar. Webflow Cloud ejecuta tu aplicación en Cloudflare Workers, y el dd-trace SDK de APM de Datadog no funciona allí porque depende de Node.js async_hooks. La solución es la API de ingesta de registros HTTP de Datadog, una fetch llamada sencilla que funciona perfectamente en Workers. Eso es lo que utiliza esta guía.

¿Qué necesitas para el seguimiento de errores y la monitorización en Webflow Cloud?

Necesitas una aplicación Next.js en Webflow Cloud, una cuenta de Sentry y una cuenta de Datadog. Ambas ofrecen niveles gratuitos que cubren el desarrollo y el uso en producción con poco tráfico.

Esto es lo que necesitas:

• Un proyecto de Webflow Cloud ejecutando una aplicación Next.js
• Una cuenta de Sentry con un proyecto Next.js (sentry.io/signup)
• Una cuenta de Datadog con una clave de API (app.datadoghq.com)
• Node.js 22 o superior instalado localmente

La configuración de Sentry utiliza el asistente oficial de Next.js y lleva unos 5 minutos. Webflow Cloud ya habilita la compatibilidad con Node.js para tu Worker de forma predeterminada, que es lo que necesita el SDK de Sentry para ejecutarse. La configuración de Datadog consiste en un único archivo de utilidad y unas pocas llamadas de registro en tus Route Handlers.

4 pasos para añadir el registro de Datadog a una aplicación de Webflow Cloud que ya ejecuta Sentry

Sentry y Datadog cubren diferentes capas de observabilidad. Sentry captura excepciones no controladas con seguimientos de pila completos, contexto de usuario y metadatos de solicitud; responde a "¿qué se rompió y por qué?". Datadog recibe registros estructurados que emites deliberadamente desde los Route Handlers; responde a "¿qué está haciendo la aplicación ahora mismo?". Ejecuto ambos en todos mis proyectos de Webflow Cloud porque son complementarios, no redundantes.

Vamos con los pasos.

1. Configura tu Sentry existente para Webflow Cloud

Esta guía asume que Sentry ya está informando desde tu aplicación. Si no es así, nuestra guía sobre cómo añadir el seguimiento de errores de Sentry a una aplicación de Webflow Cloud explica cómo crear el proyecto, ejecutar npx @sentry/wizard@latest -i nextjs, y añadir el DSN como variable de entorno, tanto para Next.js como para Astro. En lugar de repetir eso aquí, esta guía comienza donde termina aquella y añade la segunda mitad del panorama.

Hay un detalle de Webflow Cloud que vale la pena confirmar antes de continuar, porque determina qué configuración de Sentry se ejecuta realmente. Webflow Cloud despliega Next.js a través del adaptador OpenNext de Cloudflare, que ejecuta tus Route Handlers en el entorno de ejecución Node.js de Next.js en lugar del entorno Edge de Next.js. Por lo tanto, sentry.server.config.ts es el archivo que se carga para tus rutas de API, y el instrumentation.ts que generó el asistente ya lo selecciona según el entorno de ejecución. No necesitas cambiar nada, pero el archivo debería verse así:

// 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. Obtén una clave de API de Datadog

Inicia sesión en app.datadoghq.com.

Ve a Organization Settings > API Keys > New Key. Ponle un nombre como webflow-cloud-prod. Copia la clave.

Añádela a .env.local y a las variables de entorno de Webflow Cloud:

DD_API_KEY=your_datadog_api_key_here
DD_SITE=datadoghq.com

DD_SITE controla qué endpoint regional usar (datadoghq.com para US1, datadoghq.eu para EU). No añadas NEXT_PUBLIC_. Esta clave debe permanecer siempre en el servidor.

3. Crea una utilidad de registro de Datadog para los Route Handlers de Webflow Cloud

El dd-trace SDK de APM requiere Node.js.

Para el entorno de ejecución edge de Webflow Cloud, usa directamente la API de ingesta de logs HTTP de Datadog. Crea una utilidad lib/logger.ts:

// 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 }),
}

El prefijo void en cada wrapper es intencional. Las llamadas de registro nunca deben bloquear la respuesta; el fetch a Datadog se ejecuta en segundo plano y cualquier fallo se descarta silenciosamente.

Para logs críticos donde necesites garantías de entrega, await sendLog(...) directamente. Según mi experiencia, el modelo "fire-and-forget" es el ideal para los Route Handlers donde la latencia de respuesta es importante.

4. Añade el registro de Datadog a los Route Handlers de Webflow Cloud

Con la utilidad de registro lista, registrar desde cualquier Route Handler es tan fácil como importar esto:

// 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 })
  }
}

El campo service en cada entrada de log agrupa los registros en el explorador de logs de Datadog. Asígnalo de forma coherente según el dominio (pedidos, autenticación, webhooks) y podrás filtrar por servicio para aislar problemas en una parte específica de la aplicación.

¿Qué estropea el seguimiento de errores y la monitorización en Webflow Cloud? Consejos para solucionar problemas

La mayoría de los problemas con Sentry y Datadog en Webflow Cloud se deben a una de estas cuatro causas: un token de compilación faltante, una exportación de instrumentación ausente, un nombre de servicio codificado o una discrepancia de región. Como cada uno falla silenciosamente, el síntoma rara vez apunta directamente a la causa.

Aquí te explico cómo reconocer cada uno y qué cambiar.

Los errores de Sentry muestran trazas de pila minificadas sin ubicaciones de origen

Los mapas de origen (source maps) no se están subiendo. Confirma que SENTRY_AUTH_TOKEN esté configurado en tus variables de entorno de Webflow Cloud y que withSentryConfig envuelva tu next.config.ts. Los mapas de origen se suben durante la compilación, por lo que un token de autenticación faltante provoca fallos silenciosos durante la compilación en lugar de errores en tiempo de ejecución.

Los errores del Route Handler llegan a Sentry pero no muestran contexto de la solicitud

La línea export const onRequestError = Sentry.captureRequestError falta en instrumentation.ts. Sin ella, los errores capturados mediante el manejo de errores predeterminado de Next.js no incluyen cabeceras de solicitud ni URL. Añade la exportación y vuelve a desplegar.

Los logs de Datadog llegan, pero todos aparecen bajo el mismo nombre de servicio

El campo service está codificado como 'webflow-app' en el valor predeterminado de la utilidad de registro. Pasa una clave service en cada llamada de registro que identifique el dominio específico del Route Handler (p. ej., service: 'webhooks'). Esa clave sobrescribe el valor predeterminado y aparece como un servicio independiente en el mapa de servicios de Datadog.

Los registros de Datadog no aparecen en el Log Explorer después de enviarlos

Comprueba que coincida con la región de Datadog de tu cuenta. Las cuentas US1 usan ; las cuentas de la UE usan DD_SITEdatadoghq.comdatadoghq.eu. Si no coinciden, los registros se envían al endpoint de ingesta de otra región, donde se aceptan (sin devolver error), pero nunca aparecen en tu cuenta.

Amplía el seguimiento de errores y la monitorización en tu aplicación de Webflow Cloud

La configuración de esta guía proporciona una observabilidad básica: excepciones no controladas en Sentry y registros estructurados en Datadog. Ambos se pueden ampliar fácilmente a partir de aquí.

Para Sentry, añade contexto de usuario a los errores usando Sentry.setUser({ id, email }) en tu middleware de autenticación o al inicio de los Route Handlers autenticados. El contexto de usuario convierte un "500 en /api/checkout" en "estos 3 usuarios específicos tuvieron un fallo en el pago entre las 14:00 y las 14:05".

Para Datadog, añade un a cada entrada de registro generada al inicio de cada solicitud. Pasa el ID de correlación a través de todas las llamadas de registro en el ciclo de vida de una solicitud y podrás reconstruir la secuencia completa de eventos para cualquier solicitud específica filtrando correlationId@correlationId:abc123 en el Log Explorer.

Explora Webflow + Sentry para conocer los patrones de webhook que sincronizan los problemas capturados en Sentry con un registro de errores en el CMS de Webflow.

Explora Webflow + Datadog para conocer la monitorización de usuarios reales y las comprobaciones sintéticas que amplían esta configuración de registro a tus páginas publicadas en Webflow.