La respuesta directa

El monitoreo es la parte que vigila tu servicio en silencio, en segundo plano. Las alertas son la parte que decide cuándo interrumpirte. La mayoría de los fundadores que operan software o productos de IA aciertan con la primera parte y fallan en la segunda, y por eso precisamente las operaciones en solitario terminan con fatiga de notificaciones: demasiados avisos, todos ruidosos, ninguno claramente accionable.

Si solo recuerdas una cosa, que sea esta separación:

  • Monitoreo te dice qué está pasando. Recoge datos, dibuja tendencias y te da dashboards que miras cuando tú decides.
  • Alertas te dice qué hacer ahora mismo. Es una señal filtrada, construida encima de los datos del monitoreo, diseñada para interrumpirte solo cuando hace falta una acción humana.

En el contexto de fiabilidad operativa para productos de software e IA, esta separación decide si duermes o si te despiertas porque un endpoint devolvió 503, si un proveedor de LLM empezó a degradarse, o si el job de sincronización nocturna simplemente se atrasó veinte minutos.

Por qué esto importa aún más en un equipo de una persona

En una organización de ingeniería normal, una alerta ruidosa es molesta pero se sobrevive: otro miembro toma la rotación o la silencias una hora. Para un fundador en solitario, una alerta a las 2 a.m. es la rotación. Cada falso positivo te cuesta sueño, foco y la productividad del día siguiente. Con las semanas, eso se acumula en fatiga de notificaciones: el tipo concreto de burnout donde dejas de confiar en tus propias herramientas.

El objetivo de una buena configuración en solitario no es más visibilidad. Son menos interrupciones, más afiladas, acompañadas de un resumen diario que te mantenga al tanto de todo lo demás sin sacarte del flujo.

La regla de los dos trabajos: qué se pagina y qué va al resumen

Antes de elegir herramientas, decide qué tipo de problema es cada alerta. Casi todo lo que hace tu servicio cae en una de tres categorías:

  1. Los clientes no pueden usar el producto ahora mismo. Tu endpoint principal devuelve errores, tu API devuelve 5xx, tu proveedor de autenticación rechaza a todo el mundo, tu servidor MCP no responde al handshake de inicialización. Esto es una página. Alguien tiene que actuar en minutos.
  2. Algo se está degradando, pero el producto sigue funcionando. Las latencias suben, la tasa de errores crece en un endpoint no crítico, el consumo de tokens de un proveedor de LLM se dispara. Esto es un aviso que merece una notificación en horario laboral, no una página a las 2 a.m.
  3. Algo será un problema si se ignora. Disco al 80 %, certificado TLS que caduca en 14 días, versión de una dependencia seis meses por detrás, un job batch que cada vez tarda más. Esto es material para el resumen diario. Quieres verlo, pero solo una vez, y cuando estés sentado con un café.

Apunta esta separación en un papel. Es el ejercicio más útil de toda tu configuración de monitoreo, porque te dice a qué canal pertenece cada tipo de problema.

Cómo elegir canales de alerta que respeten un horario en solitario

El error más común de los fundadores independientes es usar un único canal para todo. El correo se convierte en un cementerio de alertas de importancia mezclada. Las notificaciones push se silencian. El SMS te despierta por avisos no urgentes. Elige canales por trabajo, no por comodidad.

Una mezcla práctica de canales para operaciones de una sola persona se ve así:

  • Crítico (página ya): SMS o llamada telefónica solo para caídas que afectan ingresos. Reserva este canal para la categoría de arriba: los clientes no pueden usar el producto. Cada alerta en este canal debe ser algo por lo que te despertarías de buena gana.
  • Aviso (interrumpe mi día, pero no mi noche): Notificaciones push móviles y un canal dedicado de Slack o chat. Deberían dispararse en horario de vigilia, idealmente con una ventana que respete la zona horaria. Si duermes de 23:00 a 7:00, configura horas de silencio y úsalas de verdad.
  • Resumen (infórmame, no me interrumpas): Un correo diario a una hora fija, idealmente a media mañana. Agrupa todos los avisos, degradaciones y elementos de tendencia en un solo mensaje. Léelo una vez, toma notas y sigue.

El truco es que cada canal debe llevar una categoría distinta de señal. Si el mismo tipo de problema llega por SMS y por correo, en realidad no los has separado.

Señales que importan en un producto de software o IA

El monitoreo genérico de uptime se queda corto cuando tu producto expone APIs, agentes o integraciones. Hay señales específicas que un fundador técnico debería vigilar de forma explícita:

  • Tasa de error por endpoint y por código de estado. No solo si el endpoint responde, sino cómo cambia la proporción de 4xx y 5xx a lo largo del día. Un 1 % de 5xx sostenido durante una hora es degradación; un pico del 0,05 % es ruido.
  • Percentiles de latencia, no solo promedios. El percentil 95 o 99 en los endpoints críticos suele ser el primero que avisa de una dependencia saturada, antes de que aparezca un error real. Los promedios ocultan este tipo de cola larga.
  • Headroom frente a los límites de tasa. Si trabajas con APIs de terceros con rate limits por minuto, necesitas saber qué tan cerca estás del techo antes de tocarlo, no cuando empiezas a recibir 429.
  • Salud de las dependencias externas. Proveedores de LLM, servicios de autenticación, bases de datos gestionadas, colas y caches. Una caída de un proveedor upstream puede hacer que tu producto parezca caído sin que nada tuyo haya fallado.
  • Tracking estructurado de errores. Excepciones capturadas, trazas resumidas y agrupadas por firma. Un stack trace agregado vale más que mil líneas sueltas en un log.
  • Salud de servidores MCP y endpoints de integración. Si ofreces herramientas a través de MCP u otra capa de integración, vigila el handshake, los tiempos de respuesta por herramienta y los errores por capacidad.

Una configuración fiable no se mide por cuántos paneles tienes, sino por si cada señal de esa lista tiene un destino claro: alerta, resumen o dashboard silencioso.

Reglas de ajuste que evitan la fatiga de notificaciones

Incluso con los canales correctos, los umbrales mal puestos te quemarán. Algunas reglas que ayudan de forma consistente:

  • No alertes con el primer fallo. Un único fallo es ruido. Confirma con dos o tres fallos consecutivos desde la misma región antes de paginar.
  • Agrupa alertas relacionadas. Si diez endpoints fallan porque una base de datos está caída, manda una sola alerta que diga “base de datos inaccesible” en lugar de diez que digan “endpoint X caído”. Lo mismo aplica si un proveedor de LLM devuelve errores: agrupa por proveedor, no por cada llamada.
  • Configura una notificación de recuperación. Cuando el servicio vuelve, la alerta debe decir claramente recuperado. Sin eso, pierdes diez minutos confirmando si sigue roto.
  • Incluye contexto en cada alerta. Una buena alerta nombra qué está roto, a qué clientes afecta y enlaza al dashboard o al runbook. Una mala alerta solo dice “HTTP 500” y te obliga a investigar antes siquiera de saber si te importa.
  • Crea ventanas de mantenimiento. Despliegues planeados, reinicios y actualizaciones de dependencias deben silenciar alertas por defecto. Si te ves silenciando alertas manualmente en cada despliegue, la configuración está mal.
  • Revisa tus alertas cada trimestre. Lo que necesitabas que te paginara hace seis meses probablemente ya no es lo que necesitas hoy. Cada trimestre, mira tus últimas diez páginas y pregúntate: ¿eso justificaba despertarme? Si la respuesta honesta es no, cambia el umbral o pásalo al resumen.

Respuesta a incidentes: runbook, comunicación y postmortem

Una alerta sin respuesta a incidentes definida no es operativa, es ruido. Para que la configuración sea fiable bajo presión, tres piezas mínimas tienen que existir antes de que suene la primera página seria:

  • Runbook por alerta crítica. Cada alerta que pueda paginarte debería tener un runbook corto asociado: a qué servicio apunta, qué comprobaciones rápidas hacer primero, dónde está el dashboard relevante, qué dependencias revisar, y qué acción inmediata tomar. Si tienes que improvisar a las 2 a.m. lo que mirar, la alerta llega tarde.
  • Comunicación de estado durante el incidente. Una página de estado pública, aunque sea de una sola pantalla, reduce los mensajes de soporte durante incidentes y transmite profesionalidad a los clientes. No es trabajo de marketing: es trabajo de operaciones. Define de antemano quién actualiza qué y con qué cadencia mientras dure la caída.
  • Postmortem escrito tras la recuperación. Aunque el incidente haya durado quince minutos, anota causa raíz, tiempo de detección, tiempo de mitigación, qué faltó en el runbook y qué umbral o monitor añadir. Sin postmortem, la misma caída se repite. Los postmortem internos no necesitan publicarse, pero sí necesitan escribirse y leerse.

Las tres piezas son baratas la primera vez y se amortizan en la siguiente caída que no te pilla desprevenido.

Una rutina semanal que reemplaza un guardia 24/7

No necesitas estar de guardia si tu sistema lo está por ti. La rutina semanal es lo que mantiene la honestidad de la configuración:

  • Lunes por la mañana: Lee el resumen semanal de tus herramientas de monitoreo. Fíjate en patrones: el mismo endpoint lento tres días seguidos, uso de disco creciendo, un timeout recurrente con un proveedor, un percentil de latencia subiendo semana a semana.
  • A mitad de semana: Comprueba que los monitores críticos siguen verdes y que los canales de alerta realmente entregaron una alerta de prueba. Un monitor que no puede alcanzarte es peor que no tener monitor.
  • Viernes por la tarde: Revisa todo lo que se disparó esta semana. Mueve lo ruidoso al resumen, aprieta umbrales en lo silencioso, retira monitores que ya no reflejan cómo usan los clientes el producto.

Este es el ritmo que reemplaza una rotación de guardia. No es glamuroso, pero es lo que mantiene una operación de una persona fiable sin comerse tus noches.

Trampas comunes que conviene evitar

  • Monitorearlo todo por igual. Tu atención es finita. Dedica el 80 % del esfuerzo de monitoreo al 20 % de servicios que, si se rompen, te harían perder dinero o confianza esta noche.
  • Tratar el monitoreo como alertas. Un dashboard que nunca miras es un mueble. Si no está conectado a una alerta o a un resumen, es decoración.
  • Ignorar la caducidad de certificados y dependencias. La expiración de TLS es una de las caídas más prevenibles en esta categoría. Automatiza la comprobación, ponla en el resumen y nunca vivirás un “el servicio está caído porque caducó el certificado” a las 3 a.m.
  • Saltarte la página de estado. Una página de estado pública sencilla, aunque sea de una sola pantalla, reduce los mensajes de soporte durante incidentes y transmite profesionalidad a los clientes.
  • Confundir logs con tracking estructurado de errores. Volcar excepciones a un log plano y luego buscar a mano no es tracking. Si no puedes agrupar errores por firma y ver frecuencia, estás leyendo logs, no operando errores.

Preguntas frecuentes

¿Cuál es la configuración de monitoreo más simple para un fundador en solitario que opera un producto de software o IA? Un monitor externo sobre el endpoint crítico por el que se te paga, más un watcher interno para lo básico del servidor como disco y caducidad de certificados, más tracking estructurado de errores con agrupación por firma. Todo lo demás puede esperar.

¿Debo usar SMS, correo o Slack para las alertas? Usa canales distintos para severidades distintas. SMS o teléfono solo para caídas que afectan ingresos, push móvil o Slack para avisos del mismo día, y un resumen diario por correo para todo lo demás. Nunca mezcles severidades en un único canal.

¿Cada cuánto debo comprobar mi servicio? Cada uno a cinco minutos suele bastar para un fundador en solitario. Comprobar cada diez segundos no detecta caídas más rápido, pero sí genera más ruido y puede chocar con límites de los planes hospedados.

¿Qué es realmente la fatiga de alertas? Es el punto en el que empiezas a ignorar notificaciones porque demasiadas eran falsas alarmas. Cuando silencias alertas para tener paz, tu monitoreo está fallando el trabajo para el que fue contratado.

¿Necesito monitoreo multi-región? Si tus clientes están repartidos geográficamente, sí. Si todos están en un país, dos regiones dentro de ese continente suelen bastar. La comprobación multi-región sirve sobre todo para detectar problemas de red y enrutamiento, no como cobertura por sí misma.

¿Qué pongo en un runbook si soy un equipo de una persona? Lo mínimo: qué servicio está caído, qué comprobaciones rápidas hacer primero, a qué dependencia mirar, qué acción inmediata tomar y a quién avisar. Un runbook corto escrito en un solo documento vence a uno perfecto que nunca terminas.

Fuentes