Esta guía repasa las decisiones detrás de la página de estado de un SaaS: qué poner en ella, cuándo un monitor de disponibilidad debe considerar algo una caída, cómo redactar las actualizaciones de un incidente y dónde debe estar la página. El ejemplo práctico es la página de estado con monitores de disponibilidad que acabo de añadir a Kookee, y las capturas son de Lumen, el producto de analítica inventado de mi proyecto de demostración. Uno de esos monitores se puso a prueba antes de lo previsto: mientras hacía las capturas, apagué por error el portal del proyecto de demostración, y sus dos monitores lo detectaron 68 y 78 segundos después.
Qué va en una página de estado
Una página de estado útil tiene cuatro partes:
las partes de tu producto, cada una con su estado actual;
los incidentes abiertos, con lo que sabes hasta ahora;
el mantenimiento que tienes previsto, antes de que empiece;
el pasado reciente: los incidentes de los últimos meses y cuánto de ese tiempo estuvo disponible cada parte.
Encima, una línea resume toda la página, para que un visitante que solo quiere saber si el problema está de su lado pueda dejar de leer ahí. La página de Kookee dice «Todos los sistemas funcionan con normalidad», «Interrupción leve del servicio», «Caída grave» o «Mantenimiento en curso», según los componentes y los incidentes abiertos.
Nombra los componentes como lo hacen tus clientes
Un componente es algo que un cliente puede contrastar con lo que ve. Lumen muestra Dashboards, Data ingestion, Public API, Email reports y Help center. No muestra sus workers de colas ni su base de datos, porque nadie fuera del equipo sabe qué hacen. En la captura de arriba, el incidente inventado de Lumen indica Email reports como componente afectado, y más abajo en la página ese componente aparece con «Rendimiento degradado». Un cliente al que no le llega un informe programado puede relacionarlo con lo que ve.
Kookee admite 10 componentes en el plan gratuito y 50 en Pro. Cada uno tiene una barra por día, con el color del peor estado que tuvo ese día: 90 días en una pantalla ancha, los últimos 30 en un teléfono y ninguno si desactivas Mostrar disponibilidad.
Decide cuándo un sitio está caído de verdad
Un monitor de disponibilidad solicita una URL cada cierto tiempo y tiene que decidir cuándo un fallo es una caída. La regla de Kookee son tres comprobaciones fallidas seguidas. Tras una comprobación fallida, el monitor vuelve a comprobar 20 segundos después, así que los tres fallos tardan unos 40 segundos con cualquier intervalo, o más si cada comprobación agota su tiempo de espera. El intervalo solo decide cuándo llega el primer fallo: en Pro y Ultra un monitor puede comprobar cada minuto; en el plan gratuito, cada cinco minutos como mucho. Una sola comprobación fallida no dispara nada, y con dos comprobaciones correctas seguidas el monitor vuelve a estar activo.
Así fue cuando apagué el portal de demostración. El portal se apagó a las 08:02:36 UTC. Los monitores lo declararon caído a las 08:03:44 y a las 08:03:54, cada uno tras tres 404, y el del centro de ayuda abrió un incidente en borrador, «Help center is down». El portal volvió a estar activo a las 08:04:18, los monitores se recuperaron a las 08:05:24 y a las 08:05:34, y el borrador se resolvió solo sin llegar nunca a la página pública. La caída que registró cada monitor duró más o menos lo mismo que la real y fue cerca de un minuto por detrás en ambos extremos: es el precio de confirmar antes de declararla.
Hay más reglas que deciden si puedes fiarte del monitor. Un monitor que nunca ha superado una comprobación solo avisa a tu equipo, porque una errata en la URL no debería mostrar a tus clientes una caída que nunca ocurrió. Una vez que ha estado activo, un monitor caído marca su componente como «Caída grave» sea cual sea su configuración, así que la página no puede decir «Operativo» mientras la comprobación falla. Y si el componente está en un mantenimiento programado, el monitor retiene la caída hasta que termina la ventana.
Lo que pasa después lo eliges para cada monitor: Solo avisar, Abrir un incidente en borrador o Publicar un incidente de inmediato. Con un borrador tienes un incidente listo para revisar y reescribir antes de que se publique. Publicar de inmediato encaja con una URL cuyo fallo siempre significa que los clientes están afectados, como el health check de tu API.
Escribe actualizaciones que el cliente pueda usar
Un incidente es un título y una serie de actualizaciones. Cada actualización tiene un estado, y Kookee usa cuatro para los incidentes: Investigando, Identificado, En observación y Resuelto. El título debe nombrar lo que notan los clientes («Los paneles cargaban despacio»), no la causa.
Cada actualización debe responder a lo siguiente que preguntaría un cliente. En el incidente resuelto de Lumen que ves abajo, la primera actualización dice qué está afectado, con un número: «Algunos paneles tardan más de 20 segundos en cargar». Identificado da la causa en cuanto se conoce: «La versión de esta mañana cambió cómo se consultan los gráficos de embudo grandes». En observación dice qué vigila el equipo antes de darlo por arreglado: «Estamos vigilando los tiempos de carga durante la próxima hora». El incidente de los informes por email de arriba añade lo otro que preguntan los clientes, si se pierde algo: «Los informes retrasados se enviarán igualmente y no se pierde ninguno».
En Kookee, cada actualización también fija el estado de cada componente al que afecta, así que una sola actualización cambia a la vez el incidente y la lista de componentes.
Anuncia el mantenimiento antes de que empiece
En Kookee, una ventana de mantenimiento es pública en cuanto la programas, en «Próximos mantenimientos». Está en curso entre su inicio y su fin, y sus componentes aparecen como «En mantenimiento». Después pasa a completada, sin que nadie tenga que iniciarla ni detenerla a mano. Di qué pueden notar los clientes y durante cuánto tiempo, como hace la actualización de la base de datos de Lumen: «Los paneles y la API pueden responder despacio hasta 15 minutos durante la ventana».
Cómo calcula Kookee la disponibilidad
Kookee solo cuenta como tiempo de inactividad el tiempo en «Caída grave». El rendimiento degradado y las caídas parciales colorean la barra del día, pero no bajan la cifra. El porcentaje cubre 90 días y empieza cuando se añadió el componente, así que los días anteriores salen en gris, no en verde. Se redondea hacia abajo: 99,996 % se muestra como 99,99 %, nunca como 100,00 %.
Alójala lejos del sistema que describe
Una página de estado servida por el mismo sistema que describe se cae con él. La página alojada de Kookee está en <your-project>.kookee.dev/status, aparte de tus propios servidores. Si la quieres en tu propio dominio, la misma página se construye con @kookee/react/status: StatusHeadline y StatusOverview para la página, StatusIncidentArticle para cada incidente. Sírvela desde un sitio distinto de la aplicación que describe, como un hosting estático, y deja que el navegador lea el estado desde la API de Kookee:
import { useStatus } from '@kookee/react';
import { StatusHeadline, StatusOverview } from '@kookee/react/status';
const { data: status } = useStatus({ refreshSeconds: 60 });
if (!status) return null;
<StatusHeadline status={status} />
<StatusOverview status={status} incidentHref="/status/incidents/{id}" />Las lecturas de estado no cuentan para tus solicitudes mensuales a la API. En cualquiera de las cuatro plantillas iniciales de Kookee, KOOKEE_STATUS=true añade /status y una página por incidente. Kookee tiene la misma limitación: la página y los componentes leen de la API de Kookee, así que si esa API se cae, tampoco pueden cargar.
Configúralo en Kookee
Abre Página de estado, ve a la pestaña Componentes y haz clic en Añadir componente para cada parte que vean los clientes.
Abre Monitor de disponibilidad, haz clic en Añadir monitor, introduce la URL, elige el Intervalo de comprobación y el Componente, y decide qué pasa Cuando se cae.
Abre Portal público, enciende el interruptor Activar el portal público si está apagado y marca Página de estado en Módulos del portal.
De vuelta en Página de estado, haz clic en Ver página de estado.
Configura una página de estado explica los incidentes y el mantenimiento, y Monitoriza tu sitio con comprobaciones de disponibilidad, todos los ajustes de un monitor.
Lo que la página de estado de Kookee aún no hace
Los visitantes no pueden suscribirse a las actualizaciones por email ni por RSS. No hay alertas por SMS ni turnos de guardia, los monitores solo hacen comprobaciones HTTP y HTTPS, y no hay páginas de estado privadas. La página alojada no puede tener un dominio propio; para ponerla en el tuyo están los componentes de React.
Preguntas frecuentes
¿La página de estado es gratuita? Sí. Todos los planes incluyen la página de estado y los monitores de disponibilidad. El plan gratuito tiene 10 componentes y 3 monitores, con comprobaciones cada 5 minutos como mucho; Pro tiene 50 componentes y 20 monitores, con comprobaciones de hasta una por minuto.
¿A quién se avisa cuando un monitor cae? A los propietarios y administradores del proyecto, en Kookee y por email. Los webhooks pueden recibir un evento monitor.down, y en Pro y Ultra las integraciones con Slack, Discord y Telegram pueden publicarlo en el canal de tu equipo.
¿Puede un asistente de IA publicar incidentes? Sí. A través del servidor MCP de Kookee, un asistente con acceso de escritura puede leer el estado y crear, actualizar y resolver incidentes.
Sigue leyendo
Configura una página de estado: cada paso en Kookee, de los componentes al mantenimiento.
Muestra tu página de estado en tu propio sitio: los componentes de React, la API y las plantillas iniciales.
Tus webhooks no deberían confiar en la URL que reciben: por qué un servidor que llama a las URLs de sus clientes tiene que comprobar adónde apuntan.