Status Pages e Incidencias

Una status page efectiva responde tres preguntas en menos de 5 segundos: ¿qué está caído ahora?, ¿cuándo estuvo caído antes?, ¿cómo me entero de lo siguiente? Sin esas tres respuestas visibles above the fold, la página no cumple su función. Los componentes deben organizarse en capas lógicas (frontend, API, datos, integraciones), el historial de uptime debe cubrir 90 días, y el método de suscripción debe estar en posición prominente o sticky.

Cada nivel de severidad debe mapearse a un color universal, una etiqueta textual inequívoca y un umbral de impacto medible. La ambiguedad en el nivel ("Issues detected") es más danina que reconocer una interrupción mayor, porque el usuario no puede tomar decisiones. WCAG 1.4.1 exige que el color nunca sea el único diferenciador: siempre acompañar con icono y etiqueta de texto.

Cada update publicado durante un incidente activo debe seguir una estructura fija de tres bloques: lo que sabemos, lo que estamos haciendo y cuando es el proximo update. Esta estructura impide que el redactor en crisis omita información y establece un ritmo de comunicación predecible que reduce la carga de soporte. El primer update debe publicarse en 15 minutos desde la detección, aunque sea solo una confirmación de que se esta investigando.

Un ETA incumplido dana más la confianza que no haberlo comunicado. La regla: publicar ETA solo cuando hay evidencia técnica concreta, con buffer de 1.5x el tiempo estimado, y actualizar proactivamente antes de que expire si no se cumplira. Nunca publicar ETA durante la fase "Investigating": sin causa raiz identificada, cualquier estimación es un over-promise garantizado.

El post-mortem publico convierte un incidente en evidencia de madurez operacional. Su objetivo no es disculparse sino demostrar comprensión causal y capacidad de remediation. Publicarlo antes de 48h (datos incompletos) o después de 5 días (percepción de ocultamiento) reduce su valor de confianza. La estructura correcta incluye: summary, timeline UTC, root cause, contributing factors, remediation con owners y fechas, y al menos un "What went well".

El mantenimiento programado es el único tipo de interrupción que el equipo controla completamente. No comunicarlo con 48h de anticipación mínima (7 días para flujos criticos como facturación o autenticación) es un error de proceso, no de infraestructura. El countdown en las últimas 2h debe mostrar días/horas/minutos, no segundos: el movimiento constante de segundos genera ansiedad sin información nueva.

Cada código de error HTTP tiene una causa distinta y requiere un copy, una acción sugerida y un comportamiento de retry diferentes. Usar el mismo template "Something went wrong" para 503, 404 y 500 esconde información critica del usuario y aumenta el costo de soporte. La acción clave del 503: preservar la URL y ofrecer retry automático. La del 404: sugerencias de navegación sin retry. La del 500: request ID visible para facilitar el debugging.