A las 9:12 a. m., el sitio dejó de responder. A las 9:45 a. m., alguien crea una página de nociones "Estado del incidente en curso". A las 10:30 a. m., los clientes ya habían inundado el soporte (y las redes sociales) por falta de un único canal. La página de estado no es un lujo post mortem: es una infraestructura de confianza que se debe construir cuando todo va bien.
Una página de estado pública muestra el estado de sus servicios, el historial de incidentes y las suscripciones a alertas. Bien hecho, alivia el soporte y encuadra la comunicación del incidente. Si se hace mal, o se crea bajo estrés, añade confusión.
Qué página útil contiene
| Elemento | Rol | Error común |
|---|---|---|
| Componentes recortados | Sitio, API, correo electrónico: no es un bloque de “todo” | Luz verde global mientras el pago está KO |
| Historial 90 días | Prueba de seriedad | Página vacía después de cada incidente |
| Suscripciones correo electrónico/RSS/webhook | Clientes informados sin llamar | Sin enlace desde pie de página o soporte |
| Mantenimiento programado | Reduce "¿está abajo?" entradas » | Anunciado sólo el día anterior |
| Alojamiento independiente | Manténgase arriba si lo presionan hacia abajo | Estado en el mismo VPS que el sitio |
Herramientas comunes: Statuspage (Atlassian), Cachet, Instatus o SaaS europeo según las restricciones del RGPD. El host también puede proporcionar una página, útil para su infraestructura, pero insuficiente para su pila.
Prepárese antes del incidente: runbook mínimo
Enumere los componentes con el propietario técnico y el contacto. Defina quién publica: una persona nombrada, no el vago "equipo". Redactar plantillas de mensajes: investigar, identificar, monitorear, resolver. Pruebe una interrupción trimestral falsa con actualizaciones y notificaciones para suscriptores. Vincule la página del sitio (pie de página, página de soporte) y la firma de soporte.
Durante el incidente, cada actualización sigue la regla: di lo que sabes, marca lo que no sabes, borra la marca de tiempo. Ningún “todo está arreglado” antes de la prueba.
Conectar monitoreo y estado
Automatice lo que puede ser: sondeos HTTP en URL críticas (página de inicio, /health, pago de API), alertas de Prometheus o UptimeRobot sobre el estado del webhook. Evite pasar a "resuelto" automáticamente sin validación humana.
El SLA de tiempo de actividad del host no reemplaza sus propias sondas de aplicación.
La parte superior: la página de estado es un contrato implícito con sus usuarios
Los anfitriones con estatus público (OVH, Scaleway, etc.) dan ejemplo en el aspecto de la infraestructura; su responsabilidad sigue siendo traducir el impacto empresarial.
Decide y avanza sin puntos ciegos
Elija una herramienta alojada fuera de su producción principal. Recorta de cuatro a seis componentes visibles en el lado de la manualidad. Entrene a un cartel de guardia y escriba plantillas de mensajes. Planificar un ejercicio bianual: falso fallo, notificación, timing. Compare hosts con historial de estado público a través del directorio.
Preguntas frecuentes
¿Necesito una página si el anfitrión tiene una?
Sí para tu capa de aplicación: certificado caducado, WordPress, API, túnel de pago. El estado de OVH o AWS no indica si su servicio empresarial está funcionando.
¿Qué componentes enumerar?
Lo que ve el usuario o lo que bloquea un pedido: sitio público, API, back office, correos electrónicos transaccionales, DNS.
¿El mismo host para el estado y el sitio?
Arriesgado: si el centro de datos cae, la página cae con él. Prefiere un SaaS externo u otra región.
¿Frecuencia de actualización del incidente?
Cada quince a treinta minutos mínimo con impacto importante, incluso sin causa identificada. El silencio alimenta los rumores.
Configure su página de estado en un día tranquilo. El día de la avería, no tendrás ni el tiempo ni el cerebro para inventarlo, sólo para llenarlo.