Gestión de incidentes para devs en solitario: guía práctica
Resumen
Montar un sistema de gestión de incidentes en solitario no requiere los precios de PagerDuty ni runbooks de empresa. El núcleo de las buenas prácticas cabe en tres cosas: saber cuándo algo se rompe, saber qué hacer, y comunicarlo a tus usuarios. Esta guía cubre qué construir, qué conectar de lo que ya existe, y qué esperar para cuando el tráfico justifique la complejidad.
La gestión de incidentes equipos dev pequeños o en solitario es lo que aprendes cuando ya es demasiado tarde. Tu API cae un domingo por la noche. Un usuario te escribe por Twitter diciendo que lleva dos horas roto. No tenías alertas, no tenías runbook, no tenías status page. Pasas 40 minutos buscando dónde mirar antes de pasar 5 minutos arreglando el problema.
No es un problema técnico de stack. Es un problema de preparación. Y la buena noticia: se resuelve en un fin de semana.
Qué se rompe primero cuando estás solo de guardia
En el primer incidente en solitario, se pasa más tiempo buscando información que arreglando el bug.
¿Dónde están los logs? ¿Qué servicio está fallando? ¿Es un problema global o solo afecta a un cliente? Esas preguntas deberían tener respuesta antes de que llegue la caída.
Prueba práctica: imagina que tu API de producción cae ahora mismo. Tienes 10 minutos. ¿Puedes encontrar los logs relevantes, identificar el componente que falla y hacer rollback o un hotfix sin abrir más de dos pestañas que no tuvieras ya abiertas? Si la respuesta es no, eso es exactamente lo que resuelve la gestión de incidentes.
Los tres pilares de un sistema de incidentes viable en solitario
Antes de construir nada, define los tres trabajos que el sistema tiene que hacer:
Detectar el problema antes de que un usuario te avise
Decirte qué hacer cuando estás medio dormido y solo tienes el contexto de la alerta
Informar a tus usuarios de lo que está pasando sin empeorar la situación
Cada herramienta de gestión de incidentes, desde PagerDuty hasta tu propio cron job, cubre uno de estos tres trabajos. Construye la versión más simple que haga los tres, luego para.
La tentación es construir hacia la versión enterprise: turnos de guardia, políticas de escalado, niveles de severidad P0 a P5, plantillas de post-mortem. Tiene sentido con 20 ingenieros y 500K usuarios. Con un dev y 500 usuarios, esas abstracciones consumen tus fines de semana y no se usan. La versión mínima viable se puede lanzar en un fin de semana.
Construir tu capa de alertas: el problema de los falsos positivos primero
Cada dev que ha construido su propio sistema de alertas tiene la misma historia: la primera regla estaba mal, y desactivó las alertas después de dos semanas de ruido.
Empieza con un solo check que importe. Un endpoint de health check que falla es suficiente.
# Health check simple (Express/Node)
app.get('/health', (req, res) => {
res.json({ status: 'ok', timestamp: Date.now() });
});Conecta un cron job que lo llame cada 60 segundos. Si falla tres veces consecutivas, recibes un SMS. Esa es tu primera capa de alertas. Cubre el 80% de los incidentes que afectan a usuarios.
La tasa de falsos positivos en este setup es casi cero. Recibes la alerta cuando el servicio realmente está caído, no cuando un pico de CPU disparó un umbral mal calibrado. Eso es lo más difícil de conseguir en las alertas: la alerta tiene que ser verdadera siempre, o aprendes a ignorarla.
Las alertas basadas en logs vienen después de que el check de uptime funcione y sea de confianza. Para stacks autohospedados, Grafana funciona bien a menor coste. Datadog tiene sentido cuando gestionas más de dos o tres servicios y quieres una vista unificada con integración con tu pipeline de despliegue.
Los runbooks: lo que escribes a las 11 PM para leer a las 3 AM
Un runbook no es documentación. La documentación explica cómo funciona algo. Un runbook le dice a una versión futura de ti, estresada, medio dormida y bajo presión, exactamente qué hacer ahora mismo.
El formato que funciona en proyectos en solitario:
¿Qué está roto? Una frase, solo síntomas observables
¿Es urgente? ¿Afecta a clientes de pago ahora mismo?
¿Qué hago? De tres a cinco pasos numerados, empezando por lo más rápido de probar
Eso es todo. Escríbelo cuando no estés en un incidente. Revísalo después de un incidente para ver si fue realmente útil.
El argumento práctico para Notion en lugar de un archivo en el repo: el acceso móvil. Si estás durmiendo con el teléfono cerca porque tienes tráfico en producción y un mal presentimiento sobre el deploy que acabas de hacer, eso importa. GitBook es otra opción sólida si prefieres algo más estructurado que también sirva como documentación pública para desarrolladores.
Construir una status page: lo que tus usuarios realmente quieren
Tus usuarios no necesitan un dashboard de observabilidad en tiempo real. Necesitan saber dos cosas: ¿está roto para todo el mundo? ¿Sabes que está pasando?
La status page mínima viable tiene tres elementos:
Un indicador de estado con como máximo tres estados: operativo, degradado, caído
Una marca de tiempo de cuándo se actualizó el estado por última vez
Una frase en lenguaje sencillo cuando algo va mal
Los usuarios que consultan una status page durante un incidente no leen diagramas de arquitectura. Quieren dejar de depurar su propio setup porque ahora saben que el problema no está de su lado.
Construir esto lleva menos de cuatro horas:
Una página HTML estática con un snippet de JavaScript que obtiene el estado desde un endpoint
Una tabla en Supabase con dos campos:
status(enum) ymessage(texto)Un cron job que actualiza el estado según el resultado del health check
Un endpoint de admin con autenticación para escribir un mensaje manual si hace falta
La parte difícil no es la construcción. Es el hábito de actualizarla durante un incidente en lugar de ir directamente a arreglarlo. La actualización lleva 30 segundos y evita 15 emails de soporte.
Post-mortems cuando eres el único responsable
Los post-mortems en equipos grandes buscan no culpar a individuos e identificar fallos sistémicos. En solitario, tú eres el sistema. La psicología es diferente, pero la práctica sigue siendo útil.
La razón para escribir post-mortems en solitario: resolverás el mismo tipo de problema dos veces si no lo haces. En tres meses estarás mirando una consulta de base de datos que se bloqueó por un índice que no añadiste, y tendrás un vago recuerdo de haber arreglado algo parecido, pero no recordarás qué.
Un formato de cinco minutos que funciona:
Qué pasó (un párrafo, solo hechos, sin lenguaje de culpa)
Qué hiciste para arreglarlo
Un cambio a hacer en el sistema
Un cambio a hacer en el proceso
Escríbelo en el mismo sitio que tus runbooks. Se convierte en el input de la próxima actualización del runbook. En seis meses, esto crea un registro ligero de los modos de fallo de tu sistema que ninguna herramienta enterprise de post-mortems replica para un builder en solitario.
Construir tú mismo o conectar herramientas existentes
La respuesta honesta depende de dónde estés.
Cero clientes de pago: constrúyelo todo tú mismo. Cron de health check, status page, runbooks en Notion. Es el proyecto adecuado para aprender los patrones. Se puede hacer en un fin de semana. Y si decides más tarde construirlo y venderlo como producto, habrás validado los requisitos en ti mismo primero.
Clientes de pago que dependen del uptime hoy: empieza con herramientas existentes. Conecta el tier gratuito de Grafana Cloud, configura un monitor de uptime, y abre una página de runbook en Notion esta tarde. Necesitas cobertura ahora, no después de tres fines de semana de construcción.
La parte que siempre vale la pena construir tú mismo, independientemente del momento: la status page. Alójala en un dominio separado, constrúyela este fin de semana. Todo lo demás se puede ensamblar desde tiers gratuitos hasta que la complejidad justifique construirlo.
El hueco del que ninguna guía de gestión de incidentes habla
El problema no es el tooling. Son las 48 horas entre "debería configurar alertas" y "he configurado alertas de verdad".
La mayoría de los stacks de devs en solitario tienen suficientes primitivas de observabilidad para construir una primera capa de gestión de incidentes en un día. El endpoint de health check existe en algún sitio. Los logs están en algún sitio. El pipeline de despliegue tiene algún manejo de errores. Lo que falta son 90 minutos de conexión concentrada: health check a monitor de uptime, monitor de uptime a SMS o alerta de Telegram, una página de Notion con tres runbooks, una página estática con un endpoint de Supabase para el estado.
Este no es el proyecto que le haces a los usuarios. Es el proyecto que te haces a ti mismo.
Constrúyelo este fin de semana. La primera vez que algo se rompe a las 3 AM y pasas 4 minutos arreglándolo en lugar de 40 minutos buscando, entenderás por qué existen las buenas prácticas de gestión de incidentes. No porque equipos enterprise lo hayan impuesto, sino porque la alternativa es peor. Un dev con 500 usuarios que tarda 40 minutos en detectar un fallo pierde mucho más que uno con el mismo tráfico que lo detecta en 2 minutos. La diferencia no es el stack, es haber dedicado un fin de semana a cablear lo básico.