Cómo realizar el seguimiento de las métricas de aplicaciones de Webflow Cloud con los paneles de Datadog

Los registros te dicen qué pasó. Las métricas te dicen si está ocurriendo a la velocidad correcta. He gestionado proyectos de Webflow Cloud donde los registros estaban limpios, pero los tiempos de respuesta se degradaron silenciosamente durante dos semanas.

Eso no se ve en los registros sin una consulta específica; un indicador de latencia en un panel de control lo muestra al instante como una pendiente ascendente. He detectado tres degradaciones silenciosas de esta manera antes de que cualquier usuario enviara un informe.

El enfoque consiste en una utilidad de métricas basada en fetch que envía datos a la API v2 de Datadog desde tus Route Handlers, además de un panel de control de Datadog conectado a esas métricas. La dd-trace biblioteca APM de Node.js no funciona en Cloudflare Workers, pero la API de métricas de Datadog a través de fetch sí, y esa es toda la configuración.

Esto es lo que necesitas antes de empezar a conectarlo todo.

¿Qué necesitas para realizar el seguimiento de las métricas de aplicaciones de Webflow Cloud con los paneles de control de Datadog?

Necesitas un proyecto de Next.js en Webflow Cloud y una cuenta de Datadog. Las métricas y los registros usan la misma clave, pero diferentes puntos de conexión.

Aquí tienes la lista completa:

• Un proyecto de Webflow Cloud ejecutando una aplicación Next.js, ya sea desplegada o en desarrollo local
• Una cuenta de Datadog con una clave de API (app.datadoghq.com)
• Node.js 22 o superior instalado localmente

La configuración de métricas no requiere paquetes npm adicionales. Todo se ejecuta con fetch nativo.

5 pasos para realizar el seguimiento de las métricas de aplicaciones de Webflow Cloud con los paneles de control de Datadog

El enfoque cubre tres tipos de métricas:

• Recuento de solicitudes (cuántas solicitudes recibe cada Route Handler)
• Recuento de errores (cuántas fallaron)
• Indicadores de latencia (cuánto tiempo tomó cada solicitud)

Estas tres métricas son suficientes para crear un panel de control de Datadog que responda a la pregunta: "¿Está mi aplicación de Webflow Cloud funcionando correctamente ahora mismo?"

1. Obtén una clave de API de Datadog y configura las variables de entorno de Webflow Cloud

Inicia sesión en app.datadoghq.com. Ve a Organization Settings > API Keys > New Key. Asígnale un nombre a la clave webflow-cloud-metrics. Copia la clave.

Luego, busca tu sitio de Datadog, que no aparece en la página de API Keys: figura en la parte superior de My Preferences, y la forma más rápida de identificarlo es mediante el nombre de host en tu navegador mientras estás conectado. Datadog opera nueve sitios independientes (US1, US3, US5, EU1, AP1, AP2, UK1 y dos sitios gubernamentales), cada uno con su propio nombre de host de API.

No pueden compartir datos, por lo que las métricas válidas enviadas al sitio incorrecto terminarán en una organización que no estás consultando, en lugar de generar un error.

Añade ambos a .env.local y a Settings > Environment Variables de Webflow Cloud:

DD_API_KEY=your_datadog_api_key_here
DD_SITE=datadoghq.com

DD_SITEse establece de forma predeterminada en datadoghq.com (US1). Verifica la región de tu cuenta y actualízala si es necesario.

2. Crea una utilidad de métricas de Datadog para Webflow Cloud

Crea lib/metrics.ts. Esta utilidad envuelve la API de la serie v2 de Datadog y expone tres funciones: trackRequest, trackError y trackLatency.

Las tres envían sus datos a ctx.waitUntil() en lugar de usar un enfoque de "disparar y olvidar". Esa distinción es más importante de lo que parece: Cloudflare documenta que "una llamada asíncrona que no se espera ni se pasa a ctx.waitUntil() puede cancelarse cuando finaliza la invocación; lo que provoca la pérdida de registros, deja escrituras incompletas o falla silenciosamente".

Un void fetch(...) simple es exactamente esa llamada, por lo que es posible que las métricas que no encuentras más tarde nunca se hayan enviado.

waitUntilextiende la vida útil del Worker más allá de la respuesta, brindándote las dos propiedades que buscas: la respuesta no se retrasa y el envío se completa realmente.

// lib/metrics.ts

type MetricType = 1 | 3 // 1 = count, 3 = gauge

type DatadogPoint = {
  timestamp: number
  value: number
}

type DatadogSeries = {
  metric: string
  type: MetricType
  points: DatadogPoint[]
  tags: string[]
  // Datadog requires `interval` (in seconds) for count and rate
  // metrics. Omit it and your counts are not stored the way the
  // dashboard queries assume.
  interval?: number
  resources?: { name: string; type: string }[]
}

export async function submitMetric(series: DatadogSeries[]): Promise<void> {
  // Read the site per call, not at module scope: on this adapter
  // process.env is populated per request, so a module-level read can
  // silently fall back to US1 and ship your metrics to an org you
  // are not looking at.
  const site = process.env.DD_SITE ?? 'datadoghq.com'

  await fetch(`https://api.${site}/api/v2/series`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'DD-API-KEY': process.env.DD_API_KEY!,
    },
    body: JSON.stringify({
      series: series.map((s) => ({
        ...s,
        resources: s.resources ?? [{ name: 'webflow-cloud', type: 'host' }],
      })),
    }),
  })
}

type RouteContext = {
  route: string
  method: string
  status: number
  env?: string
}

function buildTags(ctx: RouteContext): string[] {
  return [
    `route:${ctx.route}`,
    `method:${ctx.method}`,
    `status:${ctx.status}`,
    `env:${ctx.env ?? process.env.NODE_ENV ?? 'development'}`,
  ]
}

// Counts carry an interval; gauges do not.
const COUNT_INTERVAL = 60

// Count: one request hit this route.
export function requestSeries(ctx: RouteContext): DatadogSeries {
  return {
    metric: 'webflow.app.request.count',
    type: 1, // count
    interval: COUNT_INTERVAL,
    points: [{ timestamp: Math.floor(Date.now() / 1000), value: 1 }],
    tags: buildTags(ctx),
  }
}

// Count: one error on this route.
export function errorSeries(ctx: RouteContext): DatadogSeries {
  return {
    metric: 'webflow.app.error.count',
    type: 1, // count
    interval: COUNT_INTERVAL,
    points: [{ timestamp: Math.floor(Date.now() / 1000), value: 1 }],
    tags: buildTags(ctx),
  }
}

// Distribution: response time in milliseconds. See the note below on
// why this is not a gauge.
export function latencySeries(ctx: RouteContext, durationMs: number): DatadogSeries {
  return {
    metric: 'webflow.app.latency.ms',
    type: 3, // gauge
    points: [{ timestamp: Math.floor(Date.now() / 1000), value: durationMs }],
    tags: buildTags(ctx),
  }
}

// Batch the series into one call. Returns the promise so the caller
// can hand it to ctx.waitUntil rather than dropping it.
export function trackAll(
  ctx: RouteContext,
  durationMs: number,
  isError: boolean
): Promise<void> {
  const series: DatadogSeries[] = [
    requestSeries(ctx),
    latencySeries(ctx, durationMs),
  ]

  if (isError) {
    series.push(errorSeries(ctx))
  }

  return submitMetric(series)
}

trackAllagrupa dos series en una solicitud exitosa y tres cuando hay un error, todo en una sola llamada. El procesamiento por lotes es importante en esta plataforma por una razón fácil de pasar por alto: Webflow Cloud solo permite seis solicitudes salientes simultáneas por invocación, con un tiempo de espera de solicitud de 20 segundos.

Un controlador que ya llama a una API y a una base de datos tiene poco margen de maniobra, y tres capturas de telemetría separadas compiten con el trabajo que la solicitud realmente debe realizar. Datadog no limita la tasa de envío de métricas, por lo que la restricción aquí es de la plataforma, no del proveedor.

La nomenclatura de las métricas sigue la convención de Datadog: separadas por puntos, en minúsculas y comenzando con un espacio de nombres. webflow.app.* agrupa todas las métricas de la aplicación Webflow Cloud bajo un mismo prefijo en el Metrics Explorer de Datadog.

3. Añade métricas de Datadog a los controladores de ruta de Webflow Cloud

El patrón es: registra la hora de inicio al principio del controlador, resuelve el estado al final y llama a trackAll con el resultado.

Envuelve todo el controlador en un bloque try/catch para que los errores también se registren:

// app/api/orders/route.ts
import { getCloudflareContext } from '@opennextjs/cloudflare'
import { trackAll } from '@/lib/metrics'
import { NextResponse, type NextRequest } from 'next/server'

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

  const { ctx } = getCloudflareContext()

  try {
    await request.json()

    // ... your order processing logic

    return NextResponse.json({ ok: true })
  } catch {
    status = 500
    return NextResponse.json({ error: 'Failed to process order' }, { status: 500 })
  } finally {
    // waitUntil keeps the Worker alive until the send completes,
    // without holding up the response. Dropping the promise here
    // instead would let the runtime cancel it.
    ctx.waitUntil(
      trackAll(
        {
          route: '/api/orders',
          method: 'POST',
          status,
        },
        Date.now() - startTime,
        status >= 500
      )
    )
  }
}

El bloque finally es el lugar adecuado para la llamada, ya que se ejecuta tanto si el controlador tuvo éxito como si falló, por lo que obtienes métricas tanto de los errores como de los aciertos.

Sin embargo, sé preciso con el orden, ya que suele describirse mal. Un bloque finally se ejecuta antes de que la función realmente devuelva un valor: JavaScript evalúa el valor de retorno, ejecuta finally hasta completarlo y solo entonces devuelve el control. Por lo tanto, finally no mantiene esto fuera de la ruta de respuesta. waitUntil sí lo hace.

Acepta la promesa, permite que la respuesta salga y mantiene la invocación activa hasta que finaliza el envío.

Para los controladores de ruta que gestionan múltiples métodos HTTP, extrae la llamada de métricas a un envoltorio compartido:

// lib/withMetrics.ts
import { getCloudflareContext } from '@opennextjs/cloudflare'
import { trackAll } from '@/lib/metrics'
import { type NextRequest, NextResponse } from 'next/server'

// This wrapper is for static routes. Next.js passes a second argument
// carrying `params` to dynamic routes like app/api/orders/[id]/route.ts,
// and this signature discards it.
type RouteHandler = (request: NextRequest) => Promise<NextResponse>

export function withMetrics(route: string, handler: RouteHandler): RouteHandler {
  return async (request: NextRequest) => {
    const { ctx } = getCloudflareContext()
    const startTime = Date.now()
    let status = 200

    try {
      const response = await handler(request)
      status = response.status
      return response
    } catch (error) {
      status = 500
      return NextResponse.json({ error: 'Internal error' }, { status: 500 })
    } finally {
      ctx.waitUntil(
        trackAll(
          { route, method: request.method, status },
          Date.now() - startTime,
          status >= 500
        )
      )
    }
  }
}

Úsalo en cualquier Route Handler:

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

async function handler(request: NextRequest): Promise<NextResponse> {
  // ... handler logic
  return NextResponse.json({ products: [] })
}

export const GET = withMetrics('/api/products', handler)

Con el wrapper listo, cada solicitud que pasa por estos controladores emite un conteo de solicitudes, un indicador de latencia y un conteo de errores en caso de fallo, sin tener que repetir la lógica de temporización en cada archivo.

Un controlador envuelto con withMetrics y otro instrumentado en línea envían datos a las mismas tres métricas, por lo que aparecen una al lado de la otra en Datadog. A continuación, confirma que esas métricas están llegando correctamente.

4. Verifica que Datadog esté recibiendo las métricas de Webflow Cloud

Envía una solicitud de prueba a uno de tus Route Handlers instrumentados en el entorno desplegado de Webflow Cloud. Dale a Datadog entre 60 y 90 segundos para procesar el envío.

Ve a Metrics > Explorer en el panel de Datadog. En el cuadro de búsqueda de métricas, escribe webflow. Si las métricas están llegando, verás webflow.app.request.count, webflow.app.error.count y webflow.app.latency.ms en la lista de autocompletado.

Haz clic en webflow.app.request.count y cambia el intervalo de tiempo a "Past 15 Minutes". Deberías ver una barra que corresponde a la solicitud que acabas de enviar.

Si no aparece ninguna métrica después de unos dos minutos, consulta la sección de solución de problemas.

5. Crea un panel de Datadog para tu aplicación de Webflow Cloud

Ve a Dashboards > New Dashboard y ponle de nombre "Webflow Cloud App". Cuando te pida elegir un diseño, selecciona Dashboards, que es la opción basada en cuadrícula. No hay ningún control etiquetado como "Grid"; las alternativas son Timeboards y Screenboards.

Añade estos cuatro widgets para cubrir los indicadores de salud principales:

Widget 1: Volumen de solicitudes a lo largo del tiempo (Timeseries)

Haz clic en Add Widget > Timeseries.

En el campo Metric, introduce:

sum:webflow.app.request.count{*} by {route}

Configura la visualización en Bars y el título en "Requests by Route". Esto muestra cuántas solicitudes recibe cada Route Handler por minuto.

Widget 2: Tasa de errores (Timeseries)

Añade otro widget de tipo Time series:

sum:webflow.app.error.count{*} by {route}

Configura la visualización en Lines, el color en rojo y el título en "Errors by Route". Colócalo debajo del widget de volumen de solicitudes para que los picos de solicitudes y los de errores se alineen visualmente.

Widget 3: Latencia promedio (Timeseries)

Añade un widget de tipo Timeseries:

avg:webflow.app.latency.ms{*} by {route}

Título: "Latencia media (ms) por ruta". Para la latencia, avg es la agregación adecuada para la mayoría de los casos de uso. Si necesitas percentiles P95 o P99, envía puntos de distribución en lugar de métricas de tipo gauge.

Widget 4: Rutas principales por número de solicitudes (Toplist)

Añade un widget de tipo Toplist:

sum:webflow.app.request.count{*} by {route}

Título: "Rutas principales". Esto muestra tus endpoints más activos de un vistazo.

Guarda el panel. Establece la ventana de tiempo predeterminada en las últimas 4 horas; es la resolución ideal para detectar degradaciones antes de que se acumulen.

Configura una alerta de latencia: Ve a Monitors > New Monitor > Metric.

Configuración:

avg:webflow.app.latency.ms{*} > 1000

Alerta cuando esta condición se mantenga durante 5 minutos. Ese umbral detecta problemas de latencia sostenidos sin activar alertas por picos transitorios. Envíala a Slack o PagerDuty.

¿Qué interrumpe el seguimiento de métricas de Datadog en Webflow Cloud?

La mayoría de los problemas con las métricas en Webflow Cloud se deben a una de estas cuatro causas: un envío cancelado antes de salir del Worker, una clave API faltante o mal configurada, métricas dirigidas al sitio de Datadog incorrecto, o un gauge al que se le solicita un percentil que no puede generar.

Cada uno falla silenciosamente porque el envío ocurre fuera de la ruta de respuesta y nunca llega a tu gestor de rutas (Route Handler).

Los síntomas a continuación corresponden a esas causas, empezando por la que produce el resultado más confuso: métricas que llegan pero se leen incorrectamente.

Las métricas aparecen en el Explorador de métricas, pero los valores son inesperadamente bajos

Vale la pena separar dos causas, ya que la utilidad anterior ya descarta la primera que suele venir a la mente.

Las marcas de tiempo no son el problema. La utilidad llama a Math.floor(Date.now() / 1000), y una marca de tiempo en milisegundos no produciría valores bajos de todos modos: Datadog solo acepta un punto dentro de los diez minutos futuros o una hora pasada, por lo que un valor en milisegundos caería decenas de miles de años en el futuro y sería descartado. Ese síntoma indica falta de datos, no datos bajos.

Los valores bajos suelen significar un colapso del gauge. Muchas solicitudes dentro de un mismo intervalo comparten etiquetas idénticas, y un gauge conserva una instantánea en lugar de un agregado, por lo que los valores por solicitud no se acumulan como lo haría un contador.

La utilidad utiliza Math.floor(Date.now() / 1000); confirma que la conversión esté aplicada. Si pasas accidentalmente milisegundos como marca de tiempo, Datadog rechazará el punto por estar "más de 10 minutos en el futuro" y lo descartará silenciosamente.

No aparecen métricas en el Explorador de métricas después de un par de minutos

Comprueba dos cosas. Primero, confirma que DD_API_KEY esté configurado en las variables de entorno para ese entorno de Webflow Cloud. Una clave faltante falla silenciosamente en el lado de tu aplicación porque el envío se ejecuta fuera de la ruta de respuesta: Datadog devuelve un 403 por una clave incorrecta, y nada en tu gestor escucha esa respuesta. Registra el estado de la respuesta una vez mientras depuras.

Añade un console.error temporal submitMetric dentro de para exponer los fallos, revisa los registros de Webflow Cloud y luego elimínalo antes de publicar.

En segundo lugar, confirma que DD_SITE coincide con la región de tu cuenta de Datadog. Si estás en EU1 (datadoghq.eu) pero DD_SITE está configurado en datadoghq.com, las métricas se enviarán a US1 y no aparecerán en tu cuenta de EU1.

La misma métrica aparece dos veces con valores diferentes

Dos controladores de ruta están enviando métricas con el mismo nombre pero sin etiquetas que los diferencien. Comprueba que route esté siempre configurado con la ruta específica del controlador (por ejemplo, /api/orders, y no /api).

Si dos controladores comparten el nombre de una métrica sin una etiqueta que los distinga, Datadog los suma y no podrás diferenciarlos.

Los valores de latencia parecen correctos, pero el panel no muestra la opción de percentil P95

Las métricas de tipo gauge no admiten agregaciones de percentiles en Datadog. Para obtener P50/P95/P99, envía puntos de distribución en lugar de puntos gauge, utilizando el endpoint POST /api/v1/distribution_points en el host de la API de tu sitio.

Cambiar el envío es solo la mitad del trabajo, por eso muchos lo intentan y siguen sin ver la opción de percentil. Las agregaciones de percentiles en una métrica de distribución están desactivadas por defecto y deben habilitarse para esa métrica específica en la página de Resumen de Métricas. Haz ambas cosas, o nada cambiará.

El formato de la carga útil también difiere de v2/series, y las distribuciones cuestan bastante más (consulta la nota de facturación en las preguntas frecuentes). Para la mayoría de los proyectos de Webflow Cloud, avg es suficiente; cambia cuando la visibilidad de los percentiles sea realmente importante.

Amplía las métricas del panel de Datadog en tu aplicación de Webflow Cloud

Los paneles responden a la pregunta "¿qué está pasando ahora?". Sus dos compañeros naturales son las alertas, para que un umbral te avise sin que nadie tenga que estar mirando la pantalla, y los registros, para que puedas ver por qué ocurrió un pico.

Si ya usas Sentry para las excepciones, nuestra guía de Sentry y Datadog cubre cómo añadir el registro de Datadog junto a él sin duplicar las funciones de cada herramienta.

Explora Webflow + Datadog para el monitoreo de usuarios reales (RUM) y comprobaciones sintéticas del lado del cliente, y luego combina esa vista del navegador con las métricas de solicitud, latencia y errores del lado del servidor de esta guía para observar tu aplicación de Webflow Cloud de principio a fin.