Cómo crear una página de estado sin escribir código

Para crear una página de estado sin escribir código, describe los componentes de tu servicio, los estados posibles y el historial de incidentes que quieres mostrar. Un constructor con IA levanta la página en torno a un minuto y la publica en una dirección independiente, que es justo lo que necesitas cuando tu servicio principal está caído.

Una página de estado tiene un momento de la verdad muy corto: cinco minutos después de que algo se rompa, cuando tus clientes están decidiendo si abren un ticket, escriben en redes o simplemente esperan. Si en ese momento no dice nada útil, no existe.

¿Qué tiene que mostrar una página de estado?

El contenido está bastante estandarizado porque responde siempre a las mismas preguntas. Quien entra quiere saber si el fallo es suyo o vuestro, qué parte está afectada y cuándo tendrá noticias otra vez.

• Estado global arriba. Una línea grande y sin ambigüedad: todo operativo, degradado o incidente en curso. Sin colores como único indicador, porque hay gente que no los distingue.
• Estado por componente. API, panel web, inicio de sesión, envío de correos, pagos. Separado, porque "algo va mal" no ayuda a nadie a decidir.
• Incidente en curso con marca de tiempo. Qué pasa, qué estáis haciendo y cuándo actualizaréis. La hora de la próxima actualización calma más que una estimación de arreglo.
• Historial reciente. Los últimos incidentes con su resolución. Es lo que mira un cliente potencial evaluando si sois fiables.

Lo que sobra: gráficas de disponibilidad con dos decimales durante un incidente. Nadie las lee mientras está caído el servicio, y en calma solo interesan a quien negocia un contrato.

¿Por qué debe vivir fuera de tu infraestructura?

Este es el punto que hace especial a esta página y el que más veces se hace mal. Si la página de estado está alojada en el mismo servidor que se ha caído, se cae con él, y entonces tu cliente ve dos errores en lugar de una explicación.

Publicar con un constructor con IA resuelve eso por construcción. El proyecto se publica en una dirección tipo estado-tuproducto.zugo.run que no comparte nada con tu servidor de producción, y puedes apuntarle un subdominio propio. Cuando tu servicio esté caído, esta página seguirá respondiendo.

La otra consecuencia práctica: dependencias mínimas. Una página de estado no debería depender de tu inicio de sesión, de tu base de datos principal ni de tu red de entrega de contenido. Cuantas menos piezas compartidas, más veces estará ahí cuando haga falta.

¿Qué escribir en el prompt?

Nombra los componentes tal y como los llaman tus clientes, no como los llamáis internamente. "API" y "panel" son útiles; "cluster de ingesta" no le dice nada a nadie fuera del equipo.

Crea una página de estado para [nombre del servicio].
Una sola página, carga rápida, sin imágenes pesadas.
Arriba: estado global en un bloque grande con texto e icono,
no solo color.
Debajo: lista de componentes (API, Panel web, Inicio de
sesión, Correos, Pagos), cada uno con su estado y una
línea de descripción.
Sección de incidente en curso: título, hora de inicio, qué
ocurre, qué estamos haciendo y hora de la próxima
actualización.
Historial: últimos incidentes con fecha, duración,
componentes afectados y resolución.
Al final: enlace a soporte y formulario de suscripción a
avisos con el correo.
Estilo: sobrio, alto contraste, tipografía grande, legible
en móvil, modo claro y oscuro.

Una línea vale más que todas las demás: la hora de la próxima actualización. Es lo que convierte una página de estado en una promesa verificable y lo que evita que la gente refresque cada treinta segundos.

¿Estado manual o automático?

Conviene decidirlo con las cartas boca arriba, porque aquí está el límite real de construir tu propia página. La tabla compara las tres formas de mantener el estado al día.

El tercer punto es importante y no conviene disimularlo. Un constructor con IA te da la página pública, no la sonda que comprueba cada minuto si tu API responde. Si quieres estado automático, esa comprobación la hace tu monitorización, y la página muestra el resultado. Cómo se conecta una base de datos al proyecto está en la guía sobre usar Supabase.

¿Cómo se avisa a los usuarios durante un incidente?

Una página que nadie mira durante la caída no reduce los tickets. Los avisos por correo son la mitad que falta, y se resuelven con Resend conectado al proyecto: los suscriptores se guardan y reciben el mensaje cuando abres o cierras un incidente.

La disciplina cuenta más que la herramienta. Un aviso al abrir, uno a mitad si se alarga y otro al resolver, siempre en el mismo formato. Un incidente comunicado tres veces genera menos desconfianza que uno resuelto en silencio, aunque haya durado lo mismo.

Escribe la plantilla de los mensajes antes de necesitarla. Durante una caída nadie redacta bien, y tener el texto con huecos para rellenar evita el correo defensivo que empeora las cosas.

Conviene también decidir de antemano quién declara un incidente. Sin esa regla escrita, la página se actualiza tarde porque cada persona supone que lo hará otra. Un nombre por turno de guardia y una frase en el manual interno resuelven más que cualquier automatismo añadido después.

¿Cómo se escribe un incidente que calme en vez de alarmar?

El texto importa tanto como la infraestructura, y es la parte que casi nadie prepara. Un mensaje de incidente tiene que decir tres cosas: qué está afectado en palabras del cliente, qué podéis hacer mientras tanto y cuándo habrá noticias nuevas.

Lo que empeora las cosas es el lenguaje que esconde. "Estamos experimentando una degradación parcial del rendimiento en determinados servicios" sirve para no comprometerse y deja al cliente igual de perdido. "El inicio de sesión falla para parte de los usuarios desde las 14:20, estamos trabajando y actualizamos a las 15:00" resuelve la llamada al soporte.

Al cerrar el incidente, di también qué pasó y qué haréis para que no se repita, sin buscar culpables ni entrar en detalles internos innecesarios. Ese cierre publicado es la parte que construye reputación, porque casi ningún proveedor se molesta en escribirlo.

¿Cuánto cuesta y cuándo conviene un servicio dedicado?

Una página de estado es una construcción rápida de 6 créditos y cada actualización escrita cuesta 3. El plan gratuito da 5 créditos, Pro son 25 dólares al mes con 200 créditos y Business son 99 dólares al mes. Para un equipo que declara unos pocos incidentes al mes, el gasto es marginal.

Ahora la parte honesta. Los servicios dedicados a páginas de estado hacen cosas que tu página construida no hace de serie, y son buenas razones para pagarlos:

Monitorización incluida. Comprueban tus endpoints por su cuenta y cambian el estado sin que nadie intervenga a las tres de la mañana.

Avisos multicanal y suscripciones gestionadas. SMS, webhooks, integraciones con herramientas de guardia y bajas gestionadas por ellos.

Historial de disponibilidad y métricas. Cálculo de porcentajes por componente, útil si tienes acuerdos de nivel de servicio firmados.

La página propia gana en tres escenarios: cuando quieres control total del diseño y del dominio, cuando el estado lo declaráis a mano de todas formas, y cuando el coste de un servicio por asiento no se justifica todavía. Si estás en las primeras semanas de un producto, encaja con el resto de piezas descritas en la guía de la web de una startup, y el bucle general de construir y ajustar está en la de crear una app sin programar.

Si tienes claros tus componentes y tus estados, el primer prompt se escribe en zugo.dev.