Cloudflare Browser Run: cómo depurar un trabajo fallido antes de repetirlo

El 18 de septiembre de 2026, Cloudflare cambió la forma de investigar los fallos de Cloudflare Browser Run. Ahora, una grabación finalizada permite consultar los logs de consola, las solicitudes de red y la estructura final de la página. Así se puede diagnosticar con la evidencia que ya se pagó por generar antes de iniciar otro navegador.

Cloudflare Browser Run ahora deja un paquete de evidencias

Hasta ahora, al terminar un trabajo de navegador solo quedaban su resultado, el manejo de errores y una reproducción, siempre que Session Recording se hubiera activado. Si el fallo no se explicaba por sí solo, lo habitual era añadir más logs y ejecutar el trabajo otra vez.

El nuevo panel Inspect añade tres vistas junto a una grabación finalizada:

• Logs permite buscar en la salida de consola capturada y filtrarla por nivel.
• Network muestra el método, el estado, los encabezados, el payload, la respuesta y los tiempos de cada solicitud. Esa actividad se puede exportar como archivo HAR, el formato de archivo estándar para la traza de solicitudes de un navegador.
• DOM muestra la estructura de la página al final de la grabación y permite copiar el HTML reconstruido. DOM es el árbol de elementos que el navegador creó a partir de la página.

Son evidencias posteriores a la ejecución, no otra herramienta de depuración en vivo. Session Recording de Cloudflare guarda datos estructurados de eventos de rrweb, no un video. Registra cambios en el DOM, eventos de mouse y teclado, y la navegación. Cuando la sesión ya se cerró, el panel Inspect incorpora pistas que se pueden buscar alrededor de esa reproducción.

Por eso esta versión no resuelve el mismo problema que el cambio anterior de Browser Run. Las barreras de sesión y Live View de solo lectura controlan adónde puede ir un trabajo activo y qué puede hacer un cliente mientras lo observa. Inspect ayuda al propio equipo a explicar por qué falló un trabajo que ya terminó.

Qué fallos puede revelar la grabación

El panel resulta útil cuando el fallo dejó rastros en el navegador.

Un fundador de SaaS puede localizar la solicitud rechazada

Supongamos que un trabajo recurrente de extracción llega a la página, pero no devuelve datos. La vista Network puede revelar si una API respondió con 401, si un límite de solicitudes devolvió 429, si una redirección llevó el navegador a un lugar inesperado o si una dependencia consumió la mayor parte de la ejecución.

Antes de añadir logs temporales, se pueden revisar los detalles de la solicitud y la respuesta. El primer diagnóstico queda acotado: hay que corregir la credencial, la espera incremental, la redirección o la dependencia lenta que el trabajo existente ya dejó al descubierto.

Un responsable de agencia puede distinguir un cambio de página de un error del script

El flujo de un cliente puede fallar porque cambió un selector, porque apareció una página de inicio de sesión en lugar de la pantalla esperada o porque una solicitud de recursos devolvió un error. El DOM final y el HTML copiado muestran dónde terminó realmente el navegador. La traza de solicitudes muestra cómo llegó hasta allí.

El equipo de implementación recibe así un traspaso concreto. En vez de «la automatización se rompió», obtiene el árbol final de elementos y un HAR con los encabezados, payloads, estados y tiempos disponibles.

Un ingeniero de plataforma puede seguir la pestaña correcta

La grabación organiza sus arreglos de eventos por objetivos de Chrome DevTools Protocol, como target-1, y cada objetivo suele representar una pestaña del navegador. En una grabación con varias pestañas, esos objetivos aparecen por separado y el panel Inspect del dashboard sigue la pestaña seleccionada.

Esto importa en los traspasos de autenticación y en los flujos de agentes. La pestaña de inicio de sesión puede funcionar mientras falla la pestaña de trabajo. Las evidencias separadas por objetivo evitan mezclar ambas historias.

Graba un trabajo y recupera su traza de red

La grabación es opcional. Hay que habilitarla al adquirir la sesión del navegador por primera vez; no se puede activar después al reconectarse a una sesión existente.

El punto de partida mínimo y útil es una única Browser Session recurrente cuyos fallos obliguen hoy a reproducir el problema de forma manual.

1. 1

   Activa la grabación al iniciar

   El ejemplo de Puppeteer de Cloudflare pasa recording: true en la llamada inicial de lanzamiento. Conserva el ID de sesión antes de cerrar el navegador:

   import puppeteer from "@cloudflare/puppeteer";
   
   interface Env {
   	MYBROWSER: Fetcher;
   }
   
   export default {
   	async fetch(request: Request, env: Env): Promise<Response> {
   		const browser = await puppeteer.launch(env.MYBROWSER, { recording: true });
   		const page = await browser.newPage();
   
   		await page.goto("https://example.com");
   		// ... your automation steps ...
   
   		const sessionId = browser.sessionId();
   		await browser.close();
   
   		return new Response(`Session recorded: ${sessionId}`);
   	},
   };

   Playwright usa la misma opción de lanzamiento. Una conexión CDP utiliza recording=true en su URL de WebSocket.

2. 2

   Solicita la grabación finalizada

   Cuando la sesión se cierre, solicita la grabación con su ID de sesión:

   curl https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID> \
     -H "Authorization: Bearer <API_TOKEN>"

   La respuesta coloca los arreglos de eventos dentro de result.events. Sus claves, como target-1, son los ID de objetivo necesarios para pedir los datos de red. Una grabación nueva puede devolver brevemente un 404 mientras Cloudflare termina de procesarla; conviene reintentar esa consulta en lugar de interpretar el primer 404 como una ejecución inexistente.

3. 3

   Recupera las solicitudes sin procesar del objetivo

   Elige uno de los objetivos devueltos por la respuesta de la grabación. El parámetro target es obligatorio:

   curl 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID>/network?target=<TARGET_ID>' \
     -H "Authorization: Bearer <API_TOKEN>"

   La respuesta contiene las solicitudes capturadas en formato JSON, incluidos los detalles disponibles de cada solicitud y respuesta.

4. 4

   Exporta el HAR

   Añade format=har cuando un desarrollador necesite abrir la traza en el visor de red de un navegador o en otra herramienta de análisis:

   curl 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID>/network?target=<TARGET_ID>&format=har' \
     -H "Authorization: Bearer <API_TOKEN>"

   Trata ese archivo como un artefacto de depuración con una ruta de acceso breve. La respuesta documentada puede incluir encabezados y payloads disponibles, por lo que merece el mismo cuidado que los datos del trabajo que describe.

El error más fácil de cometer es activar la grabación solo después del primer fallo. No existe evidencia que se pueda inspeccionar de forma retroactiva. Hay que empezar con un trabajo recurrente cuyo próximo fallo sea relevante.

El costo del navegador no es el gasto principal

La página actual de precios de Browser Run de Cloudflare no indica un cargo separado por grabar ni por almacenar las grabaciones. Una Browser Session grabada sigue contando en la factura habitual de horas de navegador y concurrencia. Session Recording está en beta, así que debe entenderse como el precio publicado hoy, no como una promesa permanente.

Workers Free incluye 10 minutos de navegador al día y tres navegadores simultáneos. Workers Paid tiene un mínimo mensual de $5 por cuenta e incluye 10 horas de navegador y 10 navegadores simultáneos; después cobra $0.09 por cada hora adicional de navegador y $2 por cada navegador simultáneo extra, según el promedio mensual del pico de cada día.

El precio directo de una ejecución adicional para diagnosticar es mínimo; el trabajo que la rodea no lo es. Este es un modelo de planificación, no un benchmark de Cloudflare:

• La cuenta ya superó sus 10 horas de navegador incluidas.
• Un trabajo recurrente tarda 10 minutos y falla 12 veces al mes.
• Reproducir y diagnosticar cada fallo exige 20 minutos de un operador.
• Inspeccionar la grabación existente exige 5 minutos de un operador.
• Se supone un costo integral del operador de $75 por hora.
• La inspección evita una ejecución adicional de diagnóstico, aunque todavía podría hacer falta otra ejecución posterior para verificar la corrección.

Solo 18 centavos de esa diferencia corresponden al tiempo bruto de navegador. Los otros $225 son tiempo del operador. Cloudflare, además, redondea el uso del navegador a nivel de cuenta después de sumar todo el ciclo de facturación; por eso no hay que interpretar los 1.5 centavos de una ejecución de 10 minutos como una partida que aparecerá en una factura.

Esa es la consecuencia para el negocio. El panel Inspect no convierte el cómputo del navegador en un gran ahorro. Sí puede eliminar de un incidente un ciclo de añadir instrumentación, reproducir el fallo y esperar.

Lo que la grabación no puede mostrar

La grabación captura el estado del documento y los eventos, no todos los píxeles renderizados.

Esos límites determinan qué fallos todavía necesitan otro método de diagnóstico. Un gráfico dibujado en canvas, un formulario de pago dentro de un iframe de terceros, el estado de un video, una escena WebGL o un valor escrito en un campo oculto pueden estar mal aunque la grabación que los rodea parezca normal.

La vista DOM también muestra la estructura al final de la grabación. Puede explicar en qué página terminó el trabajo, pero no es una captura de pantalla píxel por píxel de todos los estados anteriores.

También hay límites operativos. Las grabaciones permanecen disponibles durante 30 días, duran al menos 1 segundo y como máximo 2 horas, y funcionan con Browser Sessions mediante launch() o CDP. Quick Actions no puede crearlas. Una página con mucha actividad puede generar un gran flujo de eventos, porque cada cambio frecuente del DOM se convierte en datos de la grabación.

Quién debería cambiar ahora su flujo de trabajo

Conviene actuar esta semana si se ejecutan trabajos recurrentes con Puppeteer, Playwright o CDP y el primer paso ante un fallo suele ser reproducirlo. Añade la grabación a un solo trabajo, no a todos, y mide si responde la primera pregunta del diagnóstico.

Conviene esperar si el estado importante vive principalmente en canvas, WebGL, contenido multimedia, un iframe de otro origen o campos de formulario ocultos. Mantén las capturas de pantalla, los logs de la aplicación y la instrumentación dirigida en ese recorrido, porque la grabación no puede sustituirlos.

Nada cambia si el trabajo se limita a Quick Actions. Migrar a Browser Sessions solo para grabar modifica la implementación y añade concurrencia al modelo de precios, así que el beneficio de depuración debe justificar el cambio.

La tarea del lunes

Elige una Browser Session recurrente que haya fallado más de una vez. Añade recording: true en su lanzamiento inicial, guarda el ID de sesión junto al ID interno del trabajo y deja que la siguiente ejecución programada se cierre con normalidad.

Después, recupera la grabación, toma el primer ID de objetivo relevante y solicita la traza de red sin procesar o el HAR. Mide cuánto se tarda en identificar la solicitud fallida o el estado final de la página. Si esa evidencia evita una ejecución adicional de diagnóstico, conserva la grabación en ese trabajo e incorpora la traza a su registro de incidentes. Si no la evita, desactívala y añade la señal que falta justo donde se encuentra el punto ciego.

Para recibir más explicaciones prácticas sobre cambios en plataformas, suscríbete al newsletter.