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

Una página de estado indica a tus usuarios, en un solo lugar, si tu servicio funciona. Para crear una necesitas una lista de componentes (sitio web, API, pagos, envío de correo), el estado actual de cada uno, incidentes con actualizaciones con marca de tiempo, un historial de incidentes pasados y, opcionalmente, suscripciones para que la gente se entere de los problemas sin tener que mirar. La página en sí es sencilla. La decisión importante es dónde se ejecuta: una página de estado debe seguir activa cuando tu app está caída, así que no debería compartir hosting, base de datos ni proceso 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 lo sabes y cuándo se arreglará. Una página de estado responde a las tres sin inundar el soporte de tickets. Además, genera confianza con el tiempo, porque un historial visible de incidentes 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 van 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 banner general («Todos los sistemas operativos» o el peor estado actual), cada componente con su estado, cualquier incidente activo con sus actualizaciones, mantenimientos próximos y una franja de historial de 90 días si tienes datos de comprobaciones.
• Página de incidente: la cronología completa de actualizaciones de un incidente, con su propia URL para que soporte pueda enlazarla.
• Historial: incidentes pasados por mes.
• Suscripción: registro por correo con confirmación y preferencias por componente.
• Administración: crear un incidente, 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: mantenerla 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 proceso,

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. Los incidentes viven en el almacenamiento de la página de estado, no en la base de datos de tu app.
• Una alternativa estática. Algunos equipos hacen la página pública estática y la regeneran con cada actualización, así que casi no hay nada que se pueda romper.

Actualizaciones manuales o comprobaciones automáticas

Manual (empieza aquí)

Tu equipo publica los incidentes 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 un juicio 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 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 de estado 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) con una red lenta. Exige dos o tres comprobaciones fallidas antes de cambiar un estado, y deja que una persona confirme antes de anunciar una caída grave.

Cómo redactar las actualizaciones de incidente

• Publica pronto. «Estamos investigando reportes de fallos al iniciar sesión» en pocos minutos vale más que un mensaje perfecto una hora después.
• Di qué notarán los usuarios, no qué se ha roto internamente.
• Anuncia cuándo será la próxima 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, Pagos, cada uno con estado Operativo, Rendimiento degradado, Caída parcial, Caída total o En mantenimiento. La página pública muestra un banner general con el peor estado actual, cada componente con su estado, los incidentes activos con actualizaciones con marca de tiempo de la más reciente a la más antigua, los mantenimientos próximos y una lista de incidentes pasados agrupados por mes. Cada incidente tiene su propia página. Añade una página de administración protegida con contraseña para crear incidentes (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 arriba/abajo desde un monitor externo, protegido con un token secreto, y que marque un componente como Degradado solo después de tres caídas consecutivas. 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 incidentes manuales. Esto ya es una página de estado funcional.
2. Aloja la página por separado y apunta un subdominio a ella.
3. Páginas de incidente e historial.
4. Ventanas de mantenimiento.
5. Suscripciones. Registro por correo con doble confirmación y avisos ante nuevos incidentes 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 un incidente falso, publica actualizaciones, resuélvelo, revisa los correos y bórralo.

Errores comunes

• Alojarla junto con la app. Es el error más frecuente 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 la app principal para la página de administración.
• Silencio entre actualizaciones. «Sin cambios, 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 suelen incluir monitorización e integraciones con herramientas de gestión de incidentes. Si la disponibilidad forma parte de lo que pagan tus clientes, o tienes obligaciones contractuales de informar de incidentes, 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.

Crea la tuya cuando quieras control total del diseño y de 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 estás creando para otros.

Crearla con Mythex

En Mythex puedes crear la página de estado como proyecto propio, separado de tu app principal, lo que le da hosting independiente y base de datos propia. 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 el plan 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 las 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