Fundamentos del monitoreo para fundadores: métricas y alertas para empezar

Qué es el monitoreo (y por qué los fundadores se sienten a ciegas sin él)

El monitoreo es cómo descubres que tu app está enferma antes de que te lo digan los usuarios. Son las señales y alertas que responden rápido a una pregunta: ¿el producto funciona ahora mismo para usuarios reales?

Los fundadores se sienten a ciegas porque la mayoría de fallos no parecen una caída total. El sitio carga, pero el login falla. Los pagos se quedan colgados para una fracción de usuarios. Un job en segundo plano deja de enviar emails. Sin monitoreo te enteras por mensajes enfadados, ingresos perdidos o un compañero que dice: “Algo se siente lento”.

El objetivo no es un dashboard perfecto. El objetivo es alerta temprana. Un buen monitoreo es silencioso en los días buenos y estruendoso en los malos.

Como mínimo, quieres saber:

• Los usuarios están fallando (y cuántos)
• Dónde está fallando (qué página, endpoint o job)
• Cuándo empezó (un timestamp claro y tendencia)
• Quién debe actuar (una alerta que llegue a la persona correcta)

Si solo sacas una cosa del monitoreo, que sea esto: poder responder “¿está roto ahora y empeora?” en menos de un minuto.

Empieza pequeño y mejora cada semana. Añade una métrica, una alerta o un detalle de log a la vez. Si heredaste una base de código generada por IA, esto importa aún más. Una app puede “funcionar” en una demo mientras oculta problemas como flujos de auth rotos, secretos expuestos o jobs en segundo plano que fallan silenciosamente.

El conjunto inicial: cuatro señales que atrapan la mayoría de fallos

La mayoría de incidentes tempranos en producción se presentan como uno de cuatro problemas: la gente encuentra errores, las páginas se vuelven lentas, la app es inaccesible o el trabajo en segundo plano deja de moverse.

Un conjunto inicial que cubre esos modos de fallo:

• Errores (tasa y tipos de error principales)
• Latencia (cuánto tardan las solicitudes clave)
• Uptime (si la app es accesible desde fuera de tu red)
• Profundidad de cola (si los jobs en segundo plano se acumulan)

Estas cuatro cubren tanto la puerta principal como la trastienda. Errores y latencia capturan lo que los usuarios sienten ahora. Uptime detecta caídas totales y fallos obvios de deploy o red. La profundidad de cola detecta fallos silenciosos que no aparecen en la UI hasta horas después.

Relacionadas con el dolor del usuario:

• Errores: “No puedo iniciar sesión” o “El pago falló”.
• Latencia: “Tarda una eternidad en cargar”, aunque técnicamente funcione.
• Uptime: “El sitio está caído”.
• Profundidad de cola: “Mi reporte nunca llegó” o “Los emails dejaron de enviarse”.

Los logs y el tracing son excelentes para el diagnóstico, pero son más difíciles de usar para alertar cuando empiezas. Métricas más alertas simples suelen llevarte más rápido a “algo anda mal”.

Errores: la forma más rápida de saber que los usuarios están bloqueados

Si solo rastreas una cosa al principio, rastrea errores. Son la señal más clara de que personas reales no pueden terminar una tarea.

Empieza con dos números:

• Tasa de error: el porcentaje de solicitudes que fallan
• Recuento de errores: cuántas fallas ocurrieron

La tasa te dice impacto. El recuento te dice volumen. Una tasa pequeña puede doler si el tráfico es alto.

Separa errores en cliente vs servidor desde temprano:

• 4xx (errores del cliente) suelen significar entrada inválida, sesiones expiradas o rutas que ya no existen.
• 5xx (errores del servidor) normalmente significan que tu sistema falló: API colapsada, query rota, deploy malo, mala configuración.

No necesitas un etiquetado perfecto el primer día, pero esta separación hace la triage más rápida.

Las alertas deben enfocarse en patrones, no en eventos únicos. Un 500 aislado puede ser ruido. Un pico o una tasa sostenida elevada es un incendio.

Un conjunto práctico inicial:

• Pico repentino: la tasa de errores sube por encima de la línea base durante 5–10 minutos
• Problema sostenido: la tasa de errores se mantiene por encima de un umbral durante 15–30 minutos
• Enfoque en 5xx: alerta sobre errores de servidor incluso si el total de errores es bajo

Añade una alerta para el “camino del dinero”: el flujo que más importa (login, signup o checkout). Si los 500 de login suben de 0.1% a 5% después de un release, quieres saberlo antes de que los clientes te escriban.

Latencia: detecta lentitud antes de que se acumulen tickets de soporte

La latencia es cuánto espera un usuario después de hacer click, tocar o refrescar. Incluso cuando tu app está “arriba”, la alta latencia se siente como rota. La gente abandona la página, reintenta o asume que su cuenta está bloqueada.

Dos números cuentan una historia clara:

• p50: la experiencia típica
• p95: la experiencia "peor común"

Si p50 está bien pero p95 sube, la mayoría de usuarios está bien, pero una porción notable está atascada esperando. Esos son los que abren tickets.

No monitorees todas las rutas el primer día. Segmenta la latencia por acciones que importan al negocio. Una página de ajustes lenta es molesta. Un login lento detiene el crecimiento.

Puntos de partida comunes:

• Login y signup
• Checkout o confirmación de pago
• Búsqueda y páginas de resultados
• Cualquier acción de “crear” (nuevo pedido, nuevo ticket, nueva publicación)

Las alertas funcionan mejor cuando detectan un cambio, no un minuto malo. Una regla simple: alerta cuando p95 sube muy por encima de lo normal, o se mantiene alto el tiempo suficiente para que los usuarios lo noten.

Un conjunto inicial útil:

• p95 es 2x la línea base durante 10 minutos
• p95 supera un límite duro (por ejemplo: 2–3 segundos) durante 5–10 minutos
• p50 sube de forma sostenida durante 15 minutos (a menudo problemas de capacidad o BD)
• p95 sube solo en un endpoint (a menudo un camino de código o API externa)

Ejemplo: la página principal sigue cargando rápido, pero el p95 del endpoint de login sube de 400ms a 4s tras un deploy. No lo notarás en una prueba rápida, pero los usuarios nuevos sí.

Uptime: confirma que la app es accesible desde el exterior

Uptime responde a una pregunta: ¿puede un usuario real alcanzar tu app ahora mismo? Detecta caídas totales, DNS mal, SSL expirado o un deploy que no volvió.

Uptime no significa que tu producto funcione. Puedes devolver 200 OK mientras el login está roto, los pagos fallan o la página está en blanco porque un script falló. Trata uptime como la alarma de humo, no como la investigación.

Usa un chequeo externo que corra desde fuera de tu infraestructura, de la misma forma que se conectan los clientes. Puede golpear tu homepage, un endpoint ligero de health o una ruta de ping que confirme que el servidor responde rápido.

Para evitar ruido, alerta sobre fallos consecutivos, no sobre un solo blip.

Una configuración inicial:

• Chequear cada 1 a 5 minutos desde al menos 2 ubicaciones
• Disparar una alerta tras 2 o 3 fallos consecutivos
• Notificar a una persona primero (push o SMS), luego escalar si no se reconoce
• Incluir la URL que falló, el código de estado y el tiempo de respuesta en la alerta

Planea también el downtime planificado. Pausa alertas o marca la ventana para no alarmarte por fallos esperados.

Ejemplo: haces un hotfix un viernes y tu configuración del reverse proxy está mal. La app “está corriendo”, pero nada es accesible desde internet. Un check de uptime externo lo detecta en minutos.

Profundidad de cola: detecta jobs en segundo plano que están atascados

Algunos de los fallos más dolorosos no aparecen como un error limpio. Aparecen como trabajo acumulado en segundo plano: emails de restablecimiento, importes de archivos, webhooks de pago, jobs de procesamiento, reportes nocturnos. La UI se ve bien mientras los clientes esperan horas.

La profundidad de cola es cuánto trabajo está esperando por procesar. También monitorea la antigüedad del job más antiguo (cuánto tiempo lleva en cola). La profundidad te dice volumen. La antigüedad te dice impacto en usuarios.

Qué monitorear

Manténlo pequeño y visible:

• Tamaño de la cola (jobs pendientes)
• Antigüedad del job más viejo (tiempo desde que el job fue encolado)
• Tasa de procesamiento (jobs completados por minuto), si está disponible

Alertas que atrapan problemas temprano

Empieza con umbrales que puedas afinar luego:

• Tamaño de cola permanece por encima de 100 durante 10 minutos
• Antigüedad del job más viejo supera 5 minutos (advertencia) o 15 minutos (urgente)
• Tamaño de cola sube durante 15 minutos mientras el tráfico es normal

Si manejas múltiples colas (emails vs importes), alerta por cola. Un worker atascado no debería esconderse detrás de otra cola saludable.

Cuando la profundidad o la antigüedad suben, la causa suele ser una de estas: un proceso worker cayó, un bucle de reintento vuelve a encolar el mismo job con fallo, o una dependencia está lenta (proveedor de email, BD, API externa).

Ejemplo: “los emails dejaron de enviarse.” El uptime está bien. Pero la antigüedad de la cola salta a 40 minutos porque el worker se cayó tras un deploy. Una alerta sobre la antigüedad de la cola lo habría detectado antes de que los clientes pidieran el link de reset.

Cómo configurar tus primeras alertas en 60 minutos (paso a paso)

No necesitas una configuración compleja el primer día. La ganancia más rápida es un pequeño conjunto de alertas ligadas a lo que realmente hacen los clientes.

Paso 1: Anota las acciones que te hacen dinero

Elige 3 a 5 acciones de usuario core. Si alguna de estas se rompe, los usuarios se bloquean rápido.

• Registrarse
• Iniciar sesión
• Empezar checkout o pagar
• Crear el objeto principal de tu app (proyecto, pedido, post)
• Exportar, invitar o compartir

Paso 2: Añade una métrica y una alerta por acción

Mantenlo mínimo: una métrica que indique que la acción falla y una alerta que realmente verás.

• Para signup y login: alerta por tasa de error (o solicitudes fallidas) en una ventana corta.
• Para pagos: alerta por picos en 4xx y 5xx y por latencia (pagos lentos a menudo fallan en silencio).
• Para crear/exportar: alerta por fallos en jobs en segundo plano o por salud de colas si se ejecuta async.

Paso 3: Establece umbrales basados en comportamiento normal

Usa los últimos días de comportamiento normal. Si los errores de login suelen estar cerca de cero, un umbral como “más de 5 fallos en 5 minutos” suele atrapar problemas reales sin ruido constante. Para latencia, empieza con “2x más lenta de lo habitual” en vez de buscar un número perfecto.

Paso 4: Envía alertas a donde realmente las verás

Una alerta que se queda en un dashboard no es una alerta. Envíala al chat del equipo, notificaciones telefónicas o donde revises durante el día.

Paso 5: Revisa semanalmente y ajusta

Una vez por semana, revisa qué alertas saltaron.

• Si una alerta es ruidosa, sube el umbral o añade una condición de duración (solo alertar si dura 10 minutos).
• Si te perdiste un incidente, baja el umbral o añade una alerta específica por flujo.

Errores comunes que hacen inútil el monitoreo

La forma más rápida de desperdiciar el monitoreo es tratarlo como un checkbox. Monitorear no es tanto tener dashboards bonitos como obtener unas pocas señales claras que conduzcan a acción.

Fatiga por alertas

Si tu teléfono vibra por cada pico pequeño, acabarás ignorando todo. Pon umbrales para que las alertas signifiquen “alguien probablemente está bloqueado” o “esto será visible por usuarios pronto”, no “un gráfico se movió”.

Solo monitorear uptime

Tu app puede estar “arriba” mientras el flujo más importante está roto (login, checkout, reset de contraseña). Si solo tienes un ping de uptime, pensarás que todo está bien mientras los clientes ven un botón girando.

Alertas sin siguiente paso

Las alertas deben apuntar a una acción siguiente, no solo a un número alarmante.

• Asigna un responsable para cada alerta (incluso si es “on-call esta semana”).
• Incluye contexto: endpoint, ventana de tiempo, cuánto de grave es.
• Añade contexto de deploy: “nuevo release hace 12 minutos” cambia cómo respondes.
• Mantén un playbook de una línea: “Si suben 500s, hacer rollback y revisar logs de auth.”

Vigilar tamaño de cola e ignorar antigüedad

Una cola pequeña puede estar rota si el job más antiguo lleva 20 minutos esperando. El tamaño muestra volumen. La antigüedad muestra si el trabajo avanza.

Ejemplo: tu worker pierde acceso a la BD tras un cambio de credenciales. La longitud de cola se mantiene porque los jobs fallan rápido y se reintentan, pero la antigüedad sube y los usuarios ven “el reporte será enviado por email” para siempre. Si alertas por antigüedad (y reintentos), lo detectas temprano.

Lista rápida: ¿estás cubierto para el próximo incidente?

Si no haces nada más esta semana, asegúrate de poder responder rápido a una pregunta: “¿Están los usuarios bloqueados ahora mismo?”

Elige objetivos que encajen con tu app hoy, y luego ajústalos.

• Errores: Una alerta para 5xx sostenidos y un umbral claro “esto es malo” en tu flujo principal (por ejemplo, >1% durante 5 minutos).
• Latencia: p95 para 2–3 endpoints clave (login, checkout, search o tu API principal), con un objetivo que los usuarios toleren (por ejemplo, p95 >1.5s durante 10 minutos).
• Uptime: Un chequeo externo que alerte solo tras fallos consecutivos (por ejemplo, 3 fallos seguidos).
• Salud de colas: Visibilidad sobre si los jobs se procesan. Alertar por antigüedad del job más viejo y por profundidad que suba lo suficiente como para quedar atrás.
• Gente/proceso: Una persona responsable cuando suena una alerta, con una vía de escalado simple.

Una prueba rápida: pide a un amigo que use tu app desde su teléfono y pruebe la acción principal. Si falla, ¿tus alertas te dirían en 5 minutos? ¿Sabrías si es por errores, lentitud, inaccesibilidad o jobs atascados?

Ejemplo: detectar un login roto antes de que los clientes lo reporten

Despliegas un cambio pequeño un viernes por la tarde: un ajuste en las pantallas de signup y login. Parece bien en tu prueba rápida. Pero para algunos usuarios, el login falla después de introducir la contraseña correcta.

En minutos, dos señales se mueven de forma que es difícil ignorar:

• Los errores suben en el endpoint de auth.
• La latencia sube al mismo tiempo, porque el backend reintenta una llamada a la BD (o a un servicio de auth externo) antes de fallar.

Si tus alertas incluyen ventanas de tiempo y contexto de deploy, puedes alinearlo con tu release y decidir rápido.

Una respuesta limpia sería:

• Hacer rollback del último deploy
• Confirmar que los errores vuelven a niveles normales
• Reenviar con un arreglo más seguro cuando haya tiempo

Después añades dos alertas dirigidas al flow de login:

• Alertar cuando la tasa de errores del endpoint de login cruza un pequeño umbral durante 5 minutos.
• Alertar por separado cuando su latencia salta respecto a la línea base.

Aquí también el código generado por IA puede ralentizarte. Puedes encontrar una llamada de login que toque tres helpers de auth diferentes, un middleware copiado y un bucle de reintento a medias. Los síntomas aparecen como errores y lentitud, mientras la causa real está enterrada en un flujo de control desordenado.

Próximos pasos: mantenlo pequeño y luego arregla las causas raíz

Empieza con un conjunto diminuto de señales y deja que los incidentes reales te digan qué añadir. El objetivo no es “cobertura perfecta”. Es notar fallos temprano y tener una acción clara.

Comienza con las cuatro señales (errores, latencia, uptime, profundidad de cola). Déjalas correr una o dos semanas. Cuando algo falle, resiste la tentación de añadir cinco alertas nuevas. Anota qué pasó y qué habría hecho que fuera obvio antes.

Una nota corta de incidente basta:

• Qué vieron los usuarios y cuándo empezó
• Qué cambió antes de que se rompiera (deploy, config, caída de tercero)
• El arreglo que implementaste (o el rollback)
• Una medida de prevención (test, guardrail, ajuste de alerta, log faltante)

Añade una alerta nueva solo si puedes responder: “Si esto dispara, ¿quién hace qué en los próximos 10 minutos?” Si la acción es “investigar eventualmente”, pertenece al dashboard, no a un pager.

Cuando las alertas siguen señalando las mismas fallas (login se rompe tras pequeños cambios, secretos llegan a logs, colas se acumulan cada noche), normalmente es un problema de la base de código, no del monitoreo. Si heredaste una app generada por IA de herramientas como Lovable, Bolt, v0, Cursor o Replit y sigue comportándose distinto en producción que en demos, una auditoría enfocada puede ahorrar muchas conjeturas. FixMyMess (fixmymess.ai) hace diagnóstico y reparación de bases de código exactamente para esa situación, incluyendo endurecimiento de seguridad y preparación de despliegues.