En algún rincón de tus herramientas de soporte hay una respuesta guardada que dice: «¿Podrías pulsar F12, abrir la pestaña Consola y enviarnos una captura de pantalla de cualquier texto en rojo?». Se envía varias veces por semana. Casi nunca vuelve con algo que sirva, y cada corrección que dependía de ella se queda parada días mientras el hilo se enfría.
Este artículo trata de cómo retirar esa respuesta. No enseñando DevTools a los usuarios, sino asegurándote de que la próxima vez que un usuario diga «la página se rompió», los errores de consola y las peticiones fallidas de su sesión ya estén en el reporte.
Por qué pedir que abran DevTools nunca funciona
La respuesta guardada falla por razones que no tienen nada que ver con la buena voluntad del usuario:
La mayoría de los usuarios nunca ha visto DevTools. El atajo de teclado cambia según la plataforma y el navegador, la pestaña Consola es una de una docena, y los stack traces en rojo parecen ruido. Le estás pidiendo a alguien que maneje un instrumento profesional, una sola vez, sin supervisión y por email.
La evidencia ya no existe. La salida de la consola dura exactamente lo que dura la pestaña. Para cuando llega tu respuesta, el usuario ya cerró la página y el error que necesitabas ya no existe en ningún sitio. Ahora le pides que reproduzca el bug a demanda, justo lo que tú no consigues hacer.
Una captura de pantalla es el formato equivocado. Incluso en el mejor caso recibes la imagen de un stack trace contraído, recortada de forma que oculta la única línea que importaba, sin marcas de tiempo ni contexto de red. No puedes buscar en ella, expandirla ni cruzarla con nada.
Suma las idas y vueltas, y pedir que abran DevTools cuesta días de espera para conseguir, en el mejor de los casos, una fracción de lo que el navegador sabía gratis en el momento del fallo.
Invierte la dirección: el navegador reporta, el usuario solo describe
La solución es dejar de hacer pasar la evidencia por la memoria y las capturas del usuario, y recogerla donde ya existe: en su navegador, en el momento del bug.
Eso es lo que hace un widget de reporte de bugs. Con BugDump instalado, la captura ya está en marcha antes de que algo se rompa: el SDK guarda una ventana móvil con las entradas de consola y la actividad de red recientes mientras el usuario navega. Cuando se topa con un problema, hace clic en el botón de bugs y escribe una frase con sus palabras. Esa frase es todo su trabajo. Todo lo que le habrías pedido viaja con ella automáticamente:
Logs de consola: las últimas 300 entradas, con errores y advertencias marcados y con búsqueda en el panel. También quedan registradas las excepciones sin capturar y las promesas rechazadas sin manejar, incluso las que tu código nunca llegó a escribir en el log.
Peticiones de red: las últimas 150, con método, código de estado y tiempos; los fallos aparecen resaltados. El 500 que precedió al fallo visible está ahí mismo, a su lado.
Entorno: navegador, sistema operativo, dispositivo, viewport y la URL exacta de la página, para que nadie vuelva a escribir «¿qué navegador usas?».
Repetición de sesión: una reconstrucción, que puedes recorrer adelante y atrás, de lo que hizo el usuario antes del reporte, para los bugs cuya causa es la secuencia de clics.
El orden es lo que hace que esto funcione. Cualquier flujo que empiece a recoger datos después de que el usuario decida reportar ya llega tarde: el error ya pasó. Como los buffers funcionan sin parar, el momento del fallo queda capturado aunque nadie, y menos que nadie el usuario, supiera que estaba a punto de ocurrir un bug.
Leer un reporte: el diagnóstico en dos minutos
Un reporte con telemetría adjunta se lee en un orden concreto, y rápido:
Lee la frase del usuario: te dice la intención («estaba intentando pagar»).
Salta a las entradas marcadas: la excepción sin capturar en la consola, la petición que falló en la lista de red.
Mira qué pasó justo antes: la petición que devolvió datos inesperados, la advertencia que saltó en la acción anterior.
Si la secuencia importa, recorre la repetición de sesión para ver en qué hizo clic de verdad el usuario.
El error de consola nombra el síntoma en tu código; el log de red suele nombrar la causa; la repetición zanja las discusiones sobre qué significa «solo hice clic normal». La mayoría de los reportes pasan de «abierto» a «sé qué archivo abrir» sin un solo mensaje al usuario: la ida y vuelta de aclaraciones que antes tardaba días ya no ocurre.
Cómo configurarlo
La instalación es una línea en cualquier web, sin paso de build y sin adaptador para tu framework:
<script src="https://bugdump.com/sdk/latest.js" async data-api-key="your-api-key"></script>Hay dos añadidos que vale la pena hacer el primer día. Si tu app tiene usuarios con sesión iniciada, llama a bugdump('identify', { email }) después del inicio de sesión para que cada reporte indique quién lo envió. Y si tus páginas cargan scripts de terceros muy ruidosos (beacons de analítica, consultas periódicas de feature flags), configura consoleFilter y networkFilter en el SDK para que los buffers guarden la actividad de tu app y no el ruido de los heartbeats. Las entradas filtradas nunca salen del navegador, así que los filtros sirven tanto de control de privacidad como de limpieza. Los cuerpos de petición y respuesta están desactivados por defecto (captureNetworkBodies los activa); déjalos así salvo que tengas un motivo concreto, e indica en tu política de privacidad que los reportes de bug incluyen logs de diagnóstico.
Después comprueba el ciclo de punta a punta: envía un reporte desde tu propia web, ábrelo en el panel de BugDump y confirma que las secciones de consola y de red muestran tu sesión. Esa prueba de dos minutos es exactamente la experiencia que tendrán tus usuarios.
Retira la macro
La respuesta guardada no desaparece del todo: se acorta. «¿Podrías hacer clic en el botón de bugs de la página y enviar un reporte?» es una petición de una línea que un usuario sí puede completar, y lo que vuelve no es una captura recortada, sino la consola, el log de red, el entorno y la repetición de sesión del momento en que se rompió.
Seguirás leyendo errores todos los días. Solo que los leerás en tu panel, desde los navegadores donde los bugs ocurrieron de verdad, en lugar de pedir a los usuarios que describan un texto rojo que nunca tuvieron por qué entender.
Te puede interesar
Cómo capturar logs de consola y peticiones de red del navegador del usuario — cómo instrumentar console, errores, fetch y XHR sin romper la página que estás monitorizando.
Repetición de sesión para depurar: mira qué hizo el usuario antes del bug — cómo funciona, qué captura y por qué combinarla con la consola y la red.
Qué hacer con un reporte de bug que no puedes reproducir — las causas habituales de un bug que no se reproduce y el contexto que las resuelve.