La versión corta

Cuando tu servicio se cae y tú eres todo el equipo, el objetivo de los primeros 30 minutos no es arreglar el bug. El objetivo es dejar de perder confianza. Fija el incidente, avisa a las personas correctas en el orden correcto y abre un único documento que irás actualizando. Las correcciones vienen después. La guía que sigue se organiza en tres fases con tiempo limitado — triaje (0–10 min), estabilización (10–30 min) y recuperación y aprendizaje (a partir de 30 min) — y termina con una plantilla de postmortem sin culpa que puedes rellenar mientras la memoria está fresca.

Si solo tienes cinco minutos, ve directo al cronograma de 30 minutos y a la plantilla de postmortem. El resto es el porqué de esos pasos.

Por qué un fundador solo necesita un runbook

La mayoría de las plantillas de runbook dan por hecho que hay a alguien más a quien llamar. Un fundador en solitario, o un equipo diminuto de dos o tres personas, no tiene rotaciones de guardia, ni responsable de comunicaciones, ni un comandante de incidentes separado. Todo el rol recae en una sola persona, a menudo de madrugada, a menudo mientras los clientes ya están tuiteando.

Justamente ahí es donde un runbook demuestra su valor. Un runbook no es una novela. Es una lista de comprobación corta y opinada que convierte el pánico en una secuencia de decisiones pequeñas. La variable que más influye en tu tiempo medio de recuperación no es tu stack — es si la siguiente acción es obvia o improvisada.

El tradeoff es real: escribir un runbook te cuesta una tarde tranquila que sientes que no tienes. La respuesta honesta es que cambias una tarde tranquila por varias noches futuras que ya no lo serán. El runbook de abajo está pensado para escribirse en una sola sesión y reutilizarse para siempre.

Lo que necesitas antes del primer incidente

No necesitas herramientas enterprise. Necesitas cuatro cosas en su sitio antes de que algo se rompa:

  1. Un único documento de incidente. Un archivo de texto plano, una página en Notion o un Google Doc con un nombre tipo inc-2025-01-14-checkout-500s. El soporte importa menos que la regla de que exista solo uno y tenga una línea de tiempo con marcas horarias.
  2. Una página de estado. Incluso el plan gratuito de los proveedores de esta categoría da a los clientes un sitio al que mirar aparte de tu bandeja de entrada. Si hoy mismo no puedes montar una, un post fijado en tu cuenta social sirve como sustituto — pero una página de estado real es bastante mejor porque no exige tu atención activa para actualizarse.
  3. Un árbol de comunicación corto. De tres a cinco direcciones de correo o usuarios de chat: tú, un backup, un cofundador si lo tienes, un contacto del proveedor de hosting o de pagos, y una persona autorizada a responder públicamente a clientes mientras tú estás centrado en depurar.
  4. Una lista de señales clave por servicio. Para cada servicio que mantienes, anota cómo es el estado “sano”: tasa de error, latencia, profundidad de cola, disco y una comprobación sintética a la que puedas llegar desde el móvil. Las usarás en la fase de triaje.

El objetivo de estos cuatro artefactos es eliminar pensamiento durante el incidente. Si a las 2 de la mañana te preguntas “¿cuál era la URL de mi dashboard otra vez?”, el runbook ya ha fallado.

El cronograma de 30 minutos

Esta es la secuencia exacta. Los tiempos son techos, no metas — si estabilizas antes, sáltate lo que sobra.

Minutos 0–10: triaje y declaración

  • Reconoce. Abre el documento de incidente en el momento en que sospeches uno, aunque no estés seguro. Un incidente sospechoso que acaba siendo falso positivo es barato. Una caída no declarada es cara.
  • Evalúa la severidad. Una escala sencilla de cuatro niveles funciona:
    • SEV1: caída total o pérdida de datos. Deja todo.
    • SEV2: funcionalidad principal rota para la mayoría de usuarios.
    • SEV3: degradación menor, existe workaround.
    • SEV4: cosmético, interno o de un solo usuario.
  • Responde cuatro preguntas: ¿Qué está afectado? ¿Cuántos usuarios? ¿El impacto sigue creciendo? ¿Afecta a ingresos o a cumplimiento? Las respuestas determinan el nivel SEV y cada cuánto actualizas a partir de ahí.
  • Avisa a tu círculo cercano. Envía un mensaje de una línea a tu árbol de comunicación: incidente declarado, nivel SEV, mejor estimación actual del impacto. Sin detalle, sin jerga, sin disculpas — solo el titular.
  • Abre el canal de comunicación. Un único hilo de chat, idealmente nombrado como el incidente, donde se registre cada decisión y observación. Si estás solo, puede ser una libreta. Si tienes equipo, debe ser un canal compartido que no sean tus DM personales.

Minutos 10–30: estabilizar

  • Corta la hemorragia antes de buscar la causa. Revierte el último deploy si el incidente empezó en la hora posterior a un release. Haz failover de la dependencia. Desactiva el flag de funcionalidad que se porta mal. Aplica throttling al endpoint abusivo. Nada de esto requiere la causa raíz.
  • Revisa las señales clave. Mira tasa de error, latencia, saturación y tráfico. Una estará obviamente mal, y esa es tu primera hipótesis, no tu conclusión.
  • Actualiza la página de estado. Incluso un mensaje corto — “Estamos investigando errores elevados en el checkout” — es mejor que el silencio. Los clientes pueden esperar; el silencio los enfada.
  • Define la cadencia de actualizaciones. SEV1 recibe una actualización cada 10–15 minutos, incluso si la actualización es “seguimos investigando”. SEV2 cada 30 minutos. SEV3 cuando algo cambia.
  • Lleva una línea de tiempo. Cada acción, cada observación, cada mensaje externo — con timestamp. La necesitarás para el postmortem y posiblemente para tickets de soporte más adelante.

Después de 30 minutos: recuperar, vigilar y documentar

  • Confirma la corrección. Comprueba que la tasa de error vuelve a la línea base, la latencia es normal y las comprobaciones sintéticas pasan. “Creo que está arreglado” no es confirmación. Los números sí.
  • Vigila la regresión durante 30–60 minutos. La mayoría de incidentes se repiten en la primera hora tras un fix porque la condición subyacente no se ha eliminado, solo se ha enmascarado.
  • Publica una nota de resolución. “Resuelto a las HH:MM. Causa raíz: X. Estamos escribiendo un postmortem completo y lo compartiremos el [fecha].”
  • Cierra el incidente. Marca el documento como cerrado, pero no lo archives. Se convierte en entrada del postmortem.

Cómo comunicar cuando eres la única voz

La parte más difícil de un incidente en solitario no es depurar — es decidir qué decir y cada cuánto. Tres reglas cargan con la mayor parte del peso.

Regla 1: di qué sabes, qué no sabes y qué estás haciendo. “El checkout está devolviendo errores 500 para un número desconocido de usuarios. Estamos investigando. Próxima actualización en 15 minutos.” Esa frase sirve igual para SEV1 que para SEV2. Es honesta, corta y crea una expectativa clara.

Regla 2: nunca prometas un tiempo del que no estés seguro. “Arreglado en 30 minutos” se convierte en mentira en cuanto se retrasa. “Estamos trabajando en ello y actualizaremos cada 15 minutos” es una promesa que puedes mantener incluso en una noche difícil.

Regla 3: un canal, una voz. Elige la página de estado o tu bandeja de soporte — no ambas, no todas. Los clientes deben saber dónde mirar. Si delegas las respuestas públicas en otra persona, instrúyela con lenguaje llano y pídele que diga “nosotros”, no “yo”.

Montar una página de estado para un negocio pequeño

Una página de estado es una de las mejoras de fiabilidad más baratas que existen. La categoría incluye servicios alojados con planes gratuitos y opciones autoalojadas. Cualquier camino funciona; la diferencia está sobre todo en cuánto quieres pensar en ello.

Cuando evalúes una herramienta de página de estado, mira:

  • Plan gratuito o casi gratuito. No deberías pagar dinero real hasta tener clientes de pago a los que les importen los SLAs.
  • Plantillas de incidente. Mensajes preescritos para “investigando”, “identificado”, “monitorizando” y “resuelto” te ahorran componer bajo estrés.
  • Suscripciones por email y webhook. Los clientes deben poder suscribirse a las actualizaciones sin iniciar sesión.
  • Soporte de dominio propio. status.tuempresa.com se ve más creíble que un subdominio de terceros.
  • Estado por componente. Si tienes más de un servicio, quieres cada uno en su propia línea.

Una decisión de configuración que vale la pena pensar antes: si suscribir a los clientes automáticamente al registrarse en tu producto o dejar la suscripción como opt-in. La auto-suscripción reduce tickets entrantes de “¿está caído?” durante incidentes. El opt-in es más amable con usuarios conscientes de la privacidad. La mayoría de productos pequeños se quedan en opt-in con un enlace visible en el footer y una línea en el email de bienvenida.

La plantilla de postmortem sin culpa que de verdad previene el próximo incidente

Un postmortem solo sirve si cambia comportamiento. La mayoría fallan porque son demasiado vagos (“necesitamos mejor monitorización”) o demasiado personales (“Alicia no vio la alerta”). La plantilla de abajo obliga a ser específico sin buscar culpables.

Sección 1: resumen

  • ID del incidente y título.
  • Fecha y hora de detección, hora de resolución, duración total.
  • Nivel SEV final, no inicial.
  • Resumen de un párrafo orientado a cliente.

Sección 2: línea de tiempo

Lista con viñetas de cada evento relevante con timestamps. Saca esto directamente del documento de incidente. Formato: HH:MM — [acción u observación] — [quién, si aplica].

Sección 3: impacto

  • Número de usuarios afectados (una estimación vale; “todos” vale).
  • Impacto en ingresos, si lo hay.
  • Tickets de soporte generados.
  • Cualquier exposición de pérdida de datos o de cumplimiento.

Sección 4: causa raíz

Escríbela en lenguaje llano que pueda seguir alguien que no sea ingeniero. “Un deploy a las 14:32 introdujo una fuga de conexiones a base de datos. Bajo carga, las conexiones se agotaron en 12 minutos, causando errores 500 en todas las rutas de escritura.” Nada de jerga por la jerga.

Distingue con cuidado entre causa próxima (el detonante inmediato), factores contribuyentes (las condiciones que lo hicieron posible) y causa raíz (lo que, arreglado, lo habría evitado). La mayoría de incidentes tienen una de cada.

Sección 5: qué salió bien

Esta sección no es opcional. Lista de tres a cinco cosas que funcionaron — un dashboard que lo cazó pronto, un rollback que aguantó, una compañera que hizo la pregunta correcta. Sin ella, el postmortem se convierte en una lista de fracasos y la gente deja de leerlos.

Sección 6: qué salió mal

Igual, de tres a cinco cosas. Formuladas como sistemas o procesos, no como personas. “La alerta saltó pero no avisó a nadie” es una observación de sistema. “Nadie se dio cuenta de la alerta” es una observación de persona y tiende a generar defensividad.

Sección 7: acciones

Cada acción necesita cuatro campos: qué va a cambiar, quién es responsable, para cuándo, y cómo sabremos que está hecho. Una acción sin dueño es un deseo. Una acción sin fecha es un deseo con fecha.

Limítate a tres o cinco acciones. Más y no se hace nada. Si tienes más de cinco, ordénalas y difiere el resto a una lista de “la próxima”.

Sección 8: aprendizajes

Un párrafo sobre lo que este incidente te enseñó sobre tu servicio, tus herramientas o tu proceso de respuesta. Esta es la sección que relees seis meses después.

Cómo hacer que el postmortem sea de verdad sin culpa

“Sin culpa” no significa “sin responsabilidad”. Significa que el postmortem describe qué pasó y por qué, no quién tuvo la culpa. En la práctica:

  • Refiérete a las personas por rol, no por nombre, al describir acciones (“la persona de guardia”, “quien desplegó”). Los nombres van solo en el campo de dueño de cada acción.
  • Asume que la persona implicada tomó la mejor decisión que pudo con la información que tenía. Si no fue así, la pregunta es qué información faltaba, no qué estaba pensando.
  • No compartas el postmortem públicamente con nombres. Internamente los nombres están bien. Externamente, solo roles.

Esto importa más para fundadores solos que para equipos grandes porque la “persona” eres tú. Un postmortem sin culpa es cómo te perdonas un error y aun así aprendes de él.

Dónde guardar el runbook y los postmortems

Tu runbook debe vivir en un sitio searchable, versionado y accesible desde el móvil. Un archivo markdown en un repo privado, un workspace en Notion o una herramienta de docs dedicada sirven. Lo que no sirve: un mensaje fijado en Slack, una nota adhesiva o tu memoria.

Tus postmortems deben vivir en el mismo sitio, etiquetados por fecha o servicio. La meta es que cuando ocurra el próximo incidente similar, puedas buscar postmortems pasados en menos de un minuto. Si no puedes, los postmortems no están rentabilizando su coste.

Preguntas frecuentes

¿Cuánto debe ocupar un runbook de respuesta a incidentes? Lo bastante para cubrir las cuatro fases de arriba, lo bastante corto para leerse en 10 minutos durante un incidente. Para un fundador solo, suele ser una o dos páginas. Cualquier cosa más larga es material de referencia, no un runbook.

¿Necesito una página de estado si todavía no tengo ingresos? No necesitas una sofisticada. Un plan gratuito de un proveedor alojado, o incluso una página pública en Notion que actualizas a mano, es suficiente. Lo que sí necesitas es un sitio único y canónico donde la respuesta a “¿está caído?” no sea tu bandeja de entrada.

¿Qué diferencia hay entre un runbook y un postmortem? Un runbook se usa durante el incidente para guiar la acción. Un postmortem se escribe después para extraer aprendizaje. Viven en el mismo sistema de documentos pero sirven a propósitos opuestos.

¿Cada cuánto debería actualizar el runbook? Tras cada incidente que haya revelado un hueco. Una cadencia razonable para un fundador solo es una vez por trimestre, más una actualización inmediata después de cualquier incidente en el que el runbook no habría ayudado.

¿Debería compartir los postmortems públicamente? A menudo, sí. Los postmortems públicos generan confianza con clientes y obligan a mantener un nivel de calidad en la redacción. Quita nombres y cualquier dato específico de cliente antes.

Fuentes