Cómo crear una status page

Una página de estado solo merece la pena si se actualiza sola durante un incidente y los clientes pueden encontrarla cuando la necesitan. Estos pasos construyen una impulsada por monitores reales desde el principio, con suficiente contexto humano para reducir ruido de soporte.

1. 1

   Decidir qué componentes mostrar

   Enumera las partes de tu producto que un cliente reconocería y le importarían por separado: el sitio o app principal, la API si otros se integran con ella, checkout o facturación si pueden fallar de forma independiente, y cualquier servicio crítico en segundo plano que los clientes noten cuando se detiene. Mantén la lista corta y significativa; de tres a seis componentes reconocibles son mejores que veinte etiquetas internas que nadie fuera de tu equipo entiende.

2. 2

   Conectar cada componente a un monitor real

   Conecta cada componente de la página al monitor que ya lo comprueba: la misma comprobación externa o heartbeat que vigila tu sitio día a día. Eso es lo que hace que la página se actualice sola: el componente se pone rojo cuando falla la comprobación subyacente y vuelve a verde cuando se recupera, sin ningún paso manual entre medias. Si un componente no tiene un monitor detrás, añade uno o déjalo fuera de la página pública.

3. 3

   Publicar y enlazarla donde la gente buscará

   Pon el enlace a la página de estado donde realmente se encontrará durante un incidente: el footer de tu sitio, la documentación, la respuesta automática de soporte, emails de onboarding y documentación de API son lugares habituales. Una página de estado técnicamente publicada pero enlazada desde ningún sitio no ahorra tickets de soporte. Si tus clientes tienen contratos o SLA, asegúrate de que la página sea el lugar que referenciarás durante una caída.

Después de publicarla

Durante un incidente real, publica una actualización breve en cuanto sepas que algo va mal, incluso antes de conocer la causa: "somos conscientes y estamos investigando" es mejor que el silencio. Actualiza de nuevo cuando tengas más información y publica una nota de resolución cuando esté arreglado. El estado automático de los componentes cubre "arriba o abajo"; una nota humana breve cubre impacto, alcance, alternativa y hora de la próxima actualización. Ambas cosas importan durante un incidente.

Qué añadir después

Cuando la página esté publicada y correctamente conectada a monitores reales, añade las piezas que reducen preguntas repetidas: una insignia de historial de uptime, suscripciones RSS o por email, y una plantilla corta de incidente que tu equipo pueda reutilizar bajo presión. Si los monitores subyacentes incluyen comprobaciones de TLS o caducidad de dominio, decide si merecen componentes visibles para clientes o si es mejor representarlas como parte del estado del sitio principal: un certificado a punto de caducar es un riesgo real, pero quizá no necesita su propia línea pública.

Errores comunes que evitar

Listar todos los componentes internos. Una página con una docena de componentes que ningún cliente reconoce es más difícil de leer de un vistazo que una con tres o cuatro que realmente les importan. Guarda el desglose detallado para una vista interna si tu equipo quiere una.

No conectarla a nada. Una página de estado no conectada a un monitor real es solo una página estática que alguien debe recordar actualizar, y eso falla justo cuando todo el mundo está más ocupado. La fuente de verdad debería ser el monitor que ya detecta el problema.

Publicarla y no enlazarla desde ningún sitio. Como en el paso 3, una página de estado publicada pero no enlazada desde tu sitio, docs o flujo de soporte no la encontrará nadie en el momento en que importa. Prueba su descubribilidad igual que pruebas las alertas: pregunta dónde miraría primero un cliente.