Cómo es una buena página de estado pública

Una página de estado pública es el lugar al que acuden los clientes durante una caída. Una buena página de estado reduce el número de tickets de soporte y genera confianza. De qué se compone.

Qué debe tener una buena página de estado

El estado actual de cada servicio clave. No solo "todo OK", sino desglosado por componentes (API, web, dashboard, emailing, payment processing).
El historial de incidentes de los últimos 90 días. Sin intentar ocultar nada - un historial transparente genera confianza.
Una métrica de uptime (normalmente de 30 días) para cada componente, expresada como un porcentaje transparente.
Mantenimiento programado. Un banner con la fecha y una descripción de lo que no estará disponible.
Incidente activo con una línea de tiempo de actualizaciones. Investigating → Identified → Monitoring → Resolved.
Un formulario de suscripción. Los clientes reciben un correo cuando cambia el estado y no tienen que consultar la página repetidamente.

Una jerarquía de componentes clara

En lugar de un único registro "monitor", divide el servicio en componentes que tengan sentido desde el punto de vista del cliente:

Web App - frontend (lo usan los visitantes)
API - backend para integraciones programáticas
Auth / Login - inicio de sesión
Email delivery - correos transaccionales
Background jobs - sync, facturación, exportaciones
Status page - componente meta: la propia página de estado también puede caerse (por eso debería ejecutarse en una infraestructura distinta a la del producto)

Incident communication: anatomía de una buena actualización

Durante una caída real, respeta estas fases:

Investigating - "Hemos identificado un problema con [componente]. El equipo está investigando la causa." (en los 5 min siguientes a la detección)
Identified - "La causa es [brevemente]. Estamos trabajando en una corrección. ETA [hora]." (cuando sabes qué causa el problema)
Monitoring - "Hemos desplegado una corrección. Estamos vigilando para asegurarnos de que el problema no se repita." (tras desplegar la solución)
Resolved - "El incidente está resuelto. Duración X minutos. Seguirá un postmortem." (tras una recuperación confirmada)

Cada fase recibe un timestamp y su propia actualización. Tras el incidente, publica un post-mortem (root cause, timeline y medidas que evitan la repetición).

Regla: Nunca uses frases vagas del tipo "experiencing some issues". Los clientes quieren concreción: "El login falla en ~30 % de los intentos. La API funciona con normalidad. La web solo está disponible en modo read-only."

Hosting: el principio de la infraestructura independiente

La página de estado debe ejecutarse en una infraestructura distinta a la del servicio monitorizado. Si tu región de AWS se cae, una página de estado alojada en la misma región se cae con ella - justo en el momento en que los clientes más la necesitan.

Soluciones prácticas:

Alojamiento mediante un SaaS externo (ePulz.io, Better Stack, Atlassian Statuspage)
Tu propia página estática en un CDN (Cloudflare Pages, Netlify) con el endpoint de la API en otro lugar
Como último recurso, una página estática mínima en Cloudflare con texto actualizado manualmente

Subscribers: correo y webhook

Los clientes no quieren refrescar la página de estado constantemente. Por eso una buena página admite:

Email subscribers - en ePulz.io disponible para usuarios con sesión iniciada y plan de pago (solo recogemos suscripciones de cuentas verificadas, no de visitantes anónimos)
Webhook - para equipos que quieren integrar el estado en su propio Slack o PagerDuty

Anti-pattern: ocultar los problemas

La tentación de marcar una caída como "degraded" en lugar de "down" (o de no mostrarla en absoluto) es grande, pero miope:

Los clientes notarán la caída de todos modos (a través de su propio monitoring, tickets de soporte o redes sociales)
Pierdes la confianza cuando descubren que el estado indica "OK" durante una caída evidente
Pierdes la imagen real de la tendencia de uptime, que necesitas para la toma de decisiones interna

La mejor estrategia es la transparencia radical. GitLab, Cloudflare y Stripe publican post-mortems detallados incluso ante errores embarazosos, y la comunidad lo valora.

SEO y marca

Una página de estado debería:

Estar en una URL estable y fácil de recordar para el estado del servicio
Tener su propio branding (logo, colores) - el cliente debe ver que sigue en tu página
Estar indexada en Google (mejor visibilidad al buscar "[marca] down")
Estar enlazada desde la página principal (footer "Estado del servicio")

Conclusión

Una página de estado no es decoración. Es una herramienta operativa que durante un incidente reduce la carga del soporte y genera confianza a largo plazo. Invertir unas horas en una configuración correcta se amortiza en cuanto llega la primera caída importante.

Crea una página de estado en 5 minutos

Páginas de estado de ePulz.io con branding personalizado, email subscribers e incident timeline. 7 días gratis.

Probar ePulz.io →