Monitoreo y seguimiento de errores en producción

Una app pequeña necesita dos tipos de monitoreo: un chequeo de disponibilidad que revisa tu sitio y tu API desde afuera cada pocos minutos y te avisa cuando dejan de responder bien, y un rastreador de errores dentro del código que registra cada fallo con la línea que lo causó. Juntos te dicen que algo se rompió, y dónde, antes de que te escriban los clientes. Para la mayoría de las apps chicas, los planes gratuitos de las herramientas habituales alcanzan para empezar.

Esta guía explica qué detecta cada capa, a qué apuntar los chequeos, cómo configurar el seguimiento de errores para que sus reportes se puedan leer y cómo lograr que las alertas sirvan en vez de molestar.

¿Qué debería monitorear una app pequeña?

Piénsalo en tres capas.

Los chequeos de disponibilidad encuentran caídas. El seguimiento de errores encuentra los fallos que solo les pasan a algunos usuarios, que un chequeo nunca ve porque la página de inicio carga bien.

¿A qué deberían apuntar los chequeos?

Un único chequeo sobre la página de inicio es la configuración más común, y la más débil. Las apps de una sola página devuelven estado 200 para el esqueleto de la página aunque los datos de atrás hayan desaparecido, así que "200 OK" puede significar "pantalla en blanco". Suma chequeos que prueben que la app funciona:

1. La página de inicio con chequeo de palabra clave. La mayoría de las herramientas pueden buscar una palabra en la página. Elige un texto que solo aparezca cuando la página se armó bien, no uno de la página de error.
2. Un endpoint de salud que toque la base de datos. Una función mínima del servidor que hace una consulta barata y devuelve 200 si funcionó y 503 si no. Que devuelva solo un estado, nunca datos.
3. Tu API o tu Edge Function principal, si el frontend depende de ella.
4. El vencimiento del certificado y del dominio. Muchas herramientas avisan antes de que venzan el certificado SSL o el registro del dominio.

Los webhooks son la excepción. Un chequeo de disponibilidad no te dice si el webhook de Stripe se está procesando. Para eso, revisa seguido el registro de entregas en el panel de Stripe, o escribe una función que te avise cuando dejan de llegar los eventos esperados. La guía sobre pagos con Stripe en una app hecha con IA muestra por qué importa.

¿Cada cuánto deberían correr?

Cada cinco minutos está bien para casi cualquier app pequeña. El plan gratis de UptimeRobot, por ejemplo, ofrece 50 monitores con intervalos de 5 minutos y se describe como pensado para proyectos personales y sin fines de lucro; su plan pago Solo revisa cada 60 segundos desde USD 12 al mes con pago anual. Los chequeos más frecuentes solo valen la pena cuando unos minutos de caída cuestan de verdad.

¿Cómo configuro un seguimiento de errores que sirva?

Sentry es una opción muy usada: su plan gratuito Developer cubre 5.000 errores al mes para un usuario, y el plan Team empieza en USD 29 al mes con 50.000 errores y usuarios ilimitados, según su página de precios. Otras herramientas funcionan igual. Elijas la que elijas, cuatro ajustes deciden si los reportes ayudan:

1. Instálalo en el frontend y en las funciones del servidor. Los errores de un lado y del otro son distintos; quieres ver los dos.
2. Sube los source maps. Sin ellos, las trazas apuntan a código minificado como index-a1b2c3.js:1:48213. Con ellos ves el archivo y la línea reales. La mayoría de las herramientas tiene un plugin para Vite y Next.js que los sube durante el build.
3. Etiqueta el entorno y la versión. Toma el entorno de la variable del hosting (en Vercel, VERCEL_ENV) para que los errores de preview no se mezclen con los de producción, y marca cada despliegue para saber qué versión trajo un error.
4. Deja afuera los datos personales. No adjuntes cuerpos de peticiones completos, contraseñas ni tokens. El SDK de JavaScript de Sentry no envía datos personales por defecto salvo que actives sendDefaultPii; déjalo apagado salvo que lo hayas decidido.

Una vez que funcione, agrega el ID del usuario (no su correo) a los errores cuando haya sesión. Así puedes responder "¿a cuántas personas les pasó?" sin guardar más de lo necesario.

¿Dónde encuentro los logs cuando algo se rompe?

• En el hosting. Vercel y Netlify muestran los logs de funciones por despliegue. Busca el momento exacto del error que reportó tu rastreador.
• En el proveedor de base de datos. El panel de Supabase tiene logs de la API, la autenticación, el almacenamiento y las Edge Functions. En los de autenticación aparecen los inicios de sesión fallidos y los errores al enviar correos.
• La retención es limitada. Cuánto historial guardan depende de tu plan, muchas veces solo días. Si necesitas más, reenvía los logs a un servicio dedicado.

¿Cómo evito que las alertas se vuelvan ruido?

• Alerta con dos fallos seguidos, no con uno. Un chequeo fallido suelto suele ser un parpadeo.
• Manda las alertas de caída a donde las vas a ver (notificación en el celular o SMS para caídas, correo para lo demás).
• Agrupa los errores por problema y alerta por problemas nuevos o picos repentinos, no por cada vez que ocurren.
• Revisa una vez por semana. Quince minutos mirando los errores principales detectan los problemas que crecen despacio.
• Mira primero a los proveedores. Cuando salta una alerta, revisa las páginas de estado del hosting y de la base de datos antes de ponerte a depurar tu código.

¿Cómo se ve una configuración mínima?

1. Un monitor con chequeo de palabra clave en la página de inicio.
2. Otro sobre un endpoint de salud que consulta la base de datos.
3. Seguimiento de errores en el frontend y en las funciones, con source maps y etiqueta de entorno.
4. Alertas al celular para caídas y por correo para errores nuevos.
5. Una nota corta con dónde vive cada log y quién recibe las alertas.

Se arma en una tarde y no cuesta nada con los planes gratis.

Respuestas rápidas

¿Alcanza con un estado 200 para saber que la app anda? No. Las apps de una sola página pueden devolver 200 mientras muestran un error o una pantalla en blanco. Usa chequeo de palabra clave y un chequeo de salud con la base de datos.

¿El monitoreo hace más lenta mi app? El seguimiento de errores suma un script pequeño al frontend; los chequeos de disponibilidad corren desde afuera y no tocan tu código. En una app típica el efecto es mínimo.

¿Necesito monitoreo antes de lanzar? Configúralo justo antes del lanzamiento, no después de la primera caída. Es la única forma de enterarte de los problemas que los usuarios no reportan.

Mi app quedó en blanco y el monitor decía que todo estaba bien. ¿Por qué? Seguramente solo revisaba el código de estado. La guía de pantalla en blanco en una app de Lovable repasa las causas habituales.

¿Quieres que alguien vigile tu app?

El monitoreo solo sirve si alguien actúa con las alertas. Nuestros planes de mantenimiento de software (Care y Care Plus) incluyen arreglos continuos y monitoreo; los detalles están en la página de precios. También puedes pasar tu app por el chequeo gratuito para tener hoy mismo una vista desde afuera.