¿Qué es una página de estado? Definición y usos

¿Qué es una página de estado?

Una página de estado es una página web pública que muestra si un servicio funciona en este momento, qué tan fiable ha sido últimamente y qué está haciendo el equipo ante un problema en curso. Es la página que abre un cliente cuando algo parece roto y quiere saber si el fallo es suyo o tuyo.

Está separada del servicio sobre el que informa, y esa separación es justamente el punto: si tu aplicación se cae, una página alojada dentro de esa aplicación también se cae. Por eso las páginas de estado se alojan de forma independiente, normalmente en otro dominio o subdominio, para seguir accesibles durante exactamente la caída que existen para explicar.

Qué contiene una página de estado

• Componentes: las partes de tu servicio que un cliente reconocería, como la API, el panel o el inicio de sesión. Cada una lleva su propio estado.
• Estado general: un único resumen arriba, para que quien visite obtenga una respuesta sin leer nada.
• Historial de disponibilidad: habitualmente una barra por componente con los últimos 30 o 90 días, un registro honesto en lugar de una afirmación.
• Incidencias: una cronología de lo ocurrido, actualizada según avanza, desde la investigación hasta la resolución.
• Mantenimiento programado: trabajos anunciados por adelantado, para que no se confundan con una caída. Consulta mantenimiento programado.
• Suscripciones: una forma de avisar a los clientes por correo cuando algo cambia, en vez de que recarguen la página.

Un ejemplo de incidencia

Imagina que la API de tu proceso de pago empieza a devolver errores. Una buena página de estado muestra esta secuencia en el componente afectado:

• Investigando: "Algunas solicitudes de pago están fallando. Estamos revisándolo."
• Identificado: "Una versión defectuosa causó los errores. Estamos revirtiéndola."
• Resuelto: "El pago vuelve a funcionar. Publicaremos un resumen."

Cada actualización lleva fecha y hora, en la barra de disponibilidad queda un hueco visible y los suscriptores reciben cada paso por correo. Los clientes ven que lo has detectado, qué está afectado y cuándo terminó, sin abrir un ticket de soporte. Cómo redactar esos mensajes se explica en comunicación de incidencias.

Páginas manuales frente a páginas impulsadas por monitores

Una página de estado puede actualizarse a mano, lo que significa que solo está tan al día como la última persona que se acordó de editarla. Durante una incidencia, esa persona suele estar ocupada resolviéndola.

Una página impulsada por monitores lee de comprobaciones que ya se ejecutan contra tu servicio, así que el estado de los componentes y el historial se actualizan solos a partir de resultados reales. La página sigue siendo exacta sin que nadie la toque, y las cifras de disponibilidad son mediciones, no promesas. La mayoría de los equipos combinan ambas cosas: los monitores cambian el estado y las personas escriben la explicación.

Errores comunes

• Alojarla en la misma infraestructura que el servicio. Cuando el servicio cae, cae también la página que debería explicarlo.
• Actualizarla tarde. Una página que sigue diciendo "todos los sistemas operativos" mientras los clientes fallan les enseña a ignorarla.
• Componentes que nadie reconoce. Nombres internos como "queue-worker-3" no dicen nada al cliente. Nombra los componentes por lo que hacen para él.
• Mostrar solo verde. Borrar incidencias u ocultar el historial elimina la prueba que da credibilidad a la página.
• Sin opción de suscripción. Los clientes no deberían tener que dejar una pestaña abierta para saber cuándo se arregla.

Páginas de estado y monitorización de disponibilidad

Como una página de estado útil se alimenta de datos de monitorización, ambas cosas están muy ligadas. La monitorización de API y la monitorización sintética aportan la señal; la página de estado la hace pública. Las cifras de disponibilidad también alimentan los compromisos que asumes en un SLA.

Páginas de estado en LoadFocus

LoadFocus publica páginas de estado impulsadas por las comprobaciones que ya ejecutas. Agrupas los monitores en secciones y componentes, cada uno con su estado en vivo y una barra de disponibilidad de 30 o 90 días. Las incidencias se pueden publicar a mano con gravedad minor, major o critical, o abrirse automáticamente cuando falla un monitor, y el mantenimiento se programa como ventanas únicas o recurrentes. Los visitantes se suscriben por correo y pueden seguir solo los componentes que les interesan. El plan gratuito incluye una página con 10 componentes y 250 suscriptores (la monitorización de API gratuita incluye esa página); un dominio propio como status.tuempresa.com está en los planes de pago. Si prefieres alojarla tú, consulta nuestra comparativa de páginas de estado autoalojadas (en inglés).

Preguntas frecuentes: páginas de estado

¿Por qué una página de estado debe alojarse por separado?

Porque tiene que funcionar cuando tu servicio no lo hace. Si está en los mismos servidores, la misma base de datos o el mismo dominio que tu aplicación, cae en la misma avería, justo cuando los clientes más la necesitan.

¿Debe una página de estado ser pública o privada?

Las páginas para clientes suelen ser públicas, para que cualquiera pueda consultarlas sin iniciar sesión. Una página privada encaja con servicios internos o con un cliente grande concreto, cuando solo deben verla las personas que elijas.

¿Puede una página de estado actualizarse sola?

Sí, si lee de comprobaciones de monitorización. El estado de los componentes y el historial siguen entonces resultados reales. La explicación de una incidencia sigue siendo mejor que la escriba una persona.

¿Qué diferencia hay entre una página de estado y la monitorización de disponibilidad?

La monitorización ejecuta las comprobaciones y avisa a tu equipo. La página de estado presenta el resultado a tus clientes. La monitorización es la fuente de los datos y la página de estado, su vista pública.

¿Necesito un dominio propio para mi página de estado?

No es obligatorio, pero status.tuempresa.com inspira más confianza y es más fácil de recordar. Mantenla en una infraestructura independiente de tu servicio principal.