Cómo crear una página de estado: componentes, incidencias y comprobaciones de disponibilidad

Una página de estado indica a tus usuarios, en un solo lugar, si tu servicio funciona. Para crearla necesitas una lista de componentes (web, API, pagos, envío de correo), el estado actual de cada uno, incidencias con actualizaciones con hora, un historial de incidencias pasadas y, opcionalmente, suscripciones para que la gente se entere de los problemas sin tener que comprobarlo. La página en sí es sencilla. La decisión importante es dónde se ejecuta: una página de estado debe seguir disponible cuando tu app no lo esté, así que no debería compartir hosting, base de datos ni canal de despliegue con aquello que informa.

Para qué sirve una página de estado

Cuando algo se rompe, los usuarios quieren saber tres cosas: si el problema es solo suyo, si ya lo sabes y cuándo se arreglará. Una página de estado responde a las tres sin que lleguen oleadas de tickets de soporte. Además genera confianza con el tiempo, porque un historial visible de incidencias, con explicaciones honestas, demuestra cómo gestionas los problemas.

No es un registro de cambios. Las novedades van en una página de cambios; las caídas y los mantenimientos, aquí.

Qué necesita la página

Datos

Los estados de los componentes suelen ser una lista corta y fija: Operativo, Rendimiento degradado, Caída parcial, Caída total, En mantenimiento.

Páginas

• Página pública de estado: un aviso general («Todos los sistemas operativos» o el peor estado actual), cada componente con su estado, cualquier incidencia activa con sus actualizaciones, próximos mantenimientos y una franja de historial de 90 días si tienes datos de comprobaciones.
• Página de incidencia: la línea temporal completa de actualizaciones de una incidencia, con su propia URL para que soporte pueda enlazarla.
• Historial: incidencias pasadas por mes.
• Suscripción: alta por correo con confirmación y preferencias por componente.
• Administración: crear una incidencia, publicar actualizaciones, cambiar el estado de los componentes y programar mantenimientos.

Permisos

El público ve todo lo publicado. Solo tu equipo puede publicar. Si puedes, mantén el acceso de administración separado del sistema de inicio de sesión de tu app principal, para que una caída de tu proveedor de autenticación no te deje fuera de tu propia página de estado.

La decisión clave: que sea independiente

Aquí es donde fallan la mayoría de las páginas de estado caseras. Si tu página de estado:

• se ejecuta en el mismo servidor o cuenta de hosting que tu app,
• lee de la misma base de datos,
• está detrás de la misma configuración de dominio o CDN,
• o la despliega el mismo canal de despliegue,

entonces muchas caídas la tumbarán también, justo cuando la gente la necesita. Pasos prácticos:

• Hosting separado. Un proyecto o proveedor distinto al de la app principal.
• Subdominio propio, como estado.ejemplo.com, apuntado por separado en el DNS. Consulta cómo funcionan los dominios y el DNS.
• Datos propios. Las incidencias viven en el almacenamiento de la página de estado, no en la base de datos de tu app.
• Un respaldo estático. Algunos equipos hacen que la página pública sea estática y la regeneran con cada actualización, así casi no hay nada que pueda romperse.

Actualizaciones manuales o comprobaciones automáticas

Manual (empieza aquí)

Tu equipo publica las incidencias y cambia el estado de los componentes a mano desde la página de administración. Así funcionan muchas páginas de estado en la práctica, porque el criterio humano («los pagos van lentos con algunos tipos de tarjeta») es más útil que un punto rojo automático.

Para enterarte de los problemas rápido, usa un monitor de disponibilidad externo que compruebe tu app cada minuto más o menos y te avise por correo, SMS o chat. Muchos servicios de monitorización tienen planes gratuitos.

Automática

La automatización significa que algo comprueba periódicamente cada componente y actualiza su estado. Eso requiere código que se ejecute con una programación, desde fuera de la infraestructura de tu app principal. Dos patrones habituales:

• Un monitor externo llama a tu página de estado mediante un webhook cuando una comprobación falla o se recupera, y la página actualiza el componente.
• Un trabajo programado en el hosting de la propia página de estado hace ping a cada componente y guarda el resultado. Revisa cómo gestiona tu hosting las tareas programadas antes de depender de ello; nuestra guía sobre ejecutar trabajos en segundo plano explica las opciones.

Los cambios automáticos pueden oscilar (arriba, abajo, arriba) en una red lenta. Exige dos o tres fallos seguidos antes de cambiar un estado, y deja que una persona confirme antes de anunciar una caída grave.

Cómo escribir las actualizaciones de incidencias

• Publica pronto. «Estamos investigando los informes de fallos al iniciar sesión» en pocos minutos vale más que un mensaje perfecto una hora después.
• Di lo que notan los usuarios, no lo que se rompió internamente.
• Indica cuándo llegará la siguiente actualización y cúmplelo.
• Cierra con un resumen breve una vez resuelto: qué pasó, cuánto duró y qué vas a cambiar.

Un primer prompt que funciona

Crea una página de estado independiente para nuestra app Parcelio, alojada por separado en estado.parcelio.com. Componentes: Web, API de seguimiento, Notificaciones y Pagos, cada uno con uno de estos estados: Operativo, Rendimiento degradado, Caída parcial, Caída total o En mantenimiento. La página pública muestra un aviso general con el peor estado actual, cada componente con su estado, las incidencias activas con actualizaciones con hora (las más recientes primero), los próximos mantenimientos y una lista de incidencias pasadas por mes. Cada incidencia tiene su propia página. Añade una página de administración protegida con contraseña para crear incidencias (título, impacto, componentes afectados), publicar actualizaciones (mensaje y estado: Investigando, Identificado, Monitorizando, Resuelto), cambiar el estado de los componentes y programar mantenimientos. Añade un endpoint POST /api/check-result que acepte el nombre de un componente y up/down desde un monitor externo, protegido con un token secreto, y que marque un componente como Degradado solo tras tres fallos consecutivos. Guarda todo en la base de datos propia de esta app. Diseño sencillo y sereno que cargue rápido en el móvil.

Pasos de construcción

1. Página pública y administración con incidencias manuales. Esto ya es una página de estado funcional.
2. Alójala por separado y apunta un subdominio hacia ella.
3. Páginas de incidencias e historial.
4. Ventanas de mantenimiento.
5. Suscripciones. Alta por correo con doble confirmación y avisos de nuevas incidencias y actualizaciones. El correo necesita un proveedor; consulta cómo enviar correos desde tu app.
6. Webhook del monitor si quieres cambios de estado automáticos.
7. Haz un simulacro. Crea una incidencia falsa, publica actualizaciones, resuélvela, revisa los correos y bórrala después.

Errores habituales

• Alojarla junto con la app. El error más común y el más grave.
• Una página que siempre dice «Todos los sistemas operativos». Si nunca muestra problemas, los usuarios dejan de confiar en ella.
• Sin marcas de tiempo ni zona horaria. Muestra siempre las horas con su zona.
• Depender del inicio de sesión de tu app principal para la página de administración.
• Silencio entre actualizaciones. «Sin novedades, seguimos trabajando en ello» es una actualización válida.
• Estados automáticos que oscilan. Exige fallos repetidos antes de cambiar un estado.

Cuándo es mejor un servicio de página de estado alojado

Los servicios de páginas de estado alojados están pensados precisamente para el problema de la independencia: funcionan en infraestructura separada, gestionan los avisos a suscriptores por correo y SMS, y a menudo incluyen monitorización e integraciones con herramientas de gestión de incidencias. Si la disponibilidad forma parte de lo que pagan tus clientes, o tienes obligaciones contractuales de informar de incidencias, un servicio dedicado suele merecer la pena. Muchos tienen planes gratuitos o de bajo coste para equipos pequeños, así que compruébalo antes de construir la tuya.

Constrúyela tú cuando quieras control total del diseño y la redacción, cuando tus necesidades sean sencillas (pocos componentes, actualizaciones manuales) o cuando la página de estado forme parte de un producto que construyes para otros.

Cómo construirla con Mythex

En Mythex puedes crear la página de estado como un proyecto propio, separado de tu app principal, lo que le da hosting independiente y su propia base de datos. Descríbela en el chat, revísala en la vista previa en directo, publícala y conecta un subdominio como estado.tudominio.com (los dominios propios están en Pro). Ten en cuenta que las apps publicadas en Mythex y sus bases de datos se duermen cuando no se usan y se despiertan en la siguiente visita, así que la primera carga tras un periodo de inactividad puede tardar más; una página sencilla y ligera ayuda.

Mythex no documenta tareas programadas, así que para comprobaciones automáticas usa un monitor de disponibilidad externo que llame a un endpoint webhook de tu página de estado (consulta la receta de webhooks). Los avisos por correo a los suscriptores pasan por tu propio proveedor, con la clave guardada como secreto del proyecto (receta de envío de correo).

Preguntas