Aprende a planificar, crear y publicar una página de estado SaaS con historial de incidentes, mensajes claros y suscripciones para que los clientes estén informados durante las caídas.
Una página de estado SaaS es un sitio público (o solo para clientes) que muestra si tu producto está funcionando ahora mismo —y qué estáis haciendo si no lo está. Se convierte en la fuente única de verdad durante incidentes, separada de redes sociales, tickets de soporte y rumores.
Ayuda a más personas de las que podrías imaginar:
Un buen sitio de estado suele contener tres capas relacionadas (pero diferentes):
El objetivo es la claridad: el estado en tiempo real responde “¿Puedo usar el producto?” mientras el historial responde “¿Con qué frecuencia pasa esto?” y los postmortems responden “¿Por qué pasó y qué cambió?”.
Una página de estado funciona cuando las actualizaciones son rápidas, en lenguaje llano y honestas respecto al impacto. No necesitas un diagnóstico perfecto para comunicar. Sí necesitas marcas temporales, alcance (quiénes están afectados) y la hora de la próxima actualización.
La usarás durante caídas, rendimiento degradado (inicios de sesión lentos, webhooks retrasados) y mantenimientos programados que puedan causar interrupciones breves o riesgo.
Si tratas la página de estado como una superficie de producto (no como una página de operaciones puntual), el resto de la configuración se vuelve mucho más fácil: puedes definir responsables, crear plantillas y conectar monitorización sin reinventar el proceso en cada incidente.
Antes de elegir una herramienta o diseñar un layout, decide qué debe hacer tu página de estado. Un objetivo claro y un responsable claro mantienen las páginas de estado útiles durante un incidente —cuando todos están ocupados y la información es confusa.
La mayoría de equipos SaaS crean una página de estado para tres resultados prácticos:
Apunta 2–3 señales medibles que puedas seguir tras el lanzamiento: menos tickets duplicados durante caídas, tiempo hasta la primera actualización más rápido o más clientes usando suscripciones.
Tu lector principal suele ser un cliente no técnico que quiere saber:
Eso significa minimizar la jerga. Prefiere “Algunos clientes no pueden iniciar sesión” antes que “Aumento de tasas 5xx en auth”. Si necesitas detalle técnico, mantenlo como una oración secundaria corta.
Escoge un tono que puedas mantener bajo presión: calmado, factual y transparente. Decide por adelantado:
Haz explícita la propiedad: la página de estado no debería ser “trabajo de todos”, porque entonces no será de nadie.
Tienes dos opciones comunes:
Si tu app principal puede caer, un sitio independiente suele ser más seguro. Aun así, puedes enlazarlo prominentemente desde tu app y centro de ayuda (por ejemplo, /help).
Una página de estado solo es útil como lo es el “mapa” detrás de ella. Antes de elegir colores o escribir copy, decide sobre qué vas a informar. El objetivo es reflejar cómo los clientes experimentan tu producto —no cómo está organizada tu org chart.
Lista las piezas que un cliente podría describir cuando dice “está roto”. Para muchos productos SaaS, un conjunto práctico inicial es:
Si ofreces múltiples regiones o planes, inclúyelo también (por ejemplo, “API – US” y “API – EU”). Usa nombres entendibles para clientes: “Login” es más claro que “IdP Gateway”.
Elige una agrupación que coincida con cómo piensan los clientes sobre tu servicio:
Evita listas interminables. Si tienes docenas de integraciones, considera un componente padre (“Integraciones”) más algunos hijos de alto impacto (p. ej., “Salesforce”, “Webhooks”).
Un modelo simple y coherente evita confusión durante incidentes. Niveles comunes incluyen:
Escribe criterios internos para cada nivel (aunque no los publiques). Por ejemplo, “Partial Outage = una región caída” o “Degraded = latencia p95 por encima de X durante Y minutos.” La consistencia genera confianza.
La mayoría de las caídas implican terceros: hosting en la nube, entrega de email, procesadores de pago o proveedores de identidad. Documenta estas dependencias para que tus actualizaciones sean precisas.
Si mostrarlas públicamente depende de tu audiencia. Si los clientes pueden verse afectados directamente (p. ej., pagos), mostrar una dependencia puede ser útil. Si añade ruido o provoca culpar a terceros, mantiene las dependencias internas pero refiérete a ellas en las actualizaciones cuando sea relevante (por ejemplo, “Investigamos errores elevados en nuestro proveedor de pagos”).
Con este modelo de componentes, el resto de la configuración de la página de estado se vuelve mucho más sencillo: cada incidente tiene un “dónde” (componente) y “qué tan grave” (estado) desde el inicio.
Una página de estado es más útil cuando responde las preguntas del cliente en segundos. La gente suele llegar estresada y quiere claridad, no mucha navegación.
Prioriza lo esencial en la parte superior:
Escribe en lenguaje llano. “Tasas de error elevadas en solicitudes API” es más claro que “Partial outage in upstream dependency.” Si debes usar términos técnicos, añade una breve traducción (“Algunas solicitudes pueden fallar o agotar tiempo”).
Un patrón fiable es:
Para la lista de componentes, usa etiquetas orientadas al cliente. Si tu servicio interno se llama “k8s-cluster-2”, los clientes probablemente necesitan “API” o “Background Jobs”.
Haz la página legible bajo presión:
Coloca un conjunto pequeño de enlaces cerca de la parte superior (en el header o justo bajo el banner):
El objetivo es confianza: los clientes deben entender de inmediato qué sucede, qué afecta y cuándo volverán a tener noticias.
Cuando ocurre un incidente, tu equipo está entre diagnóstico, mitigación y preguntas de clientes al mismo tiempo. Las plantillas eliminan la incertidumbre para que las actualizaciones sean coherentes, claras y rápidas —especialmente cuando distintas personas pueden publicar.
Una buena actualización parte de los mismos hechos cada vez. Como mínimo, estandariza estos campos para que los clientes entiendan rápidamente qué ocurre:
Si publicas una página de historial, mantener estos campos consistentes facilita escanear y comparar incidentes pasados.
Apunta a actualizaciones cortas que respondan las mismas preguntas cada vez. Aquí tienes una plantilla práctica que puedes copiar en tu herramienta de status page:
Title: Resumen breve y específico (p. ej., “Errores en API para la región EU”)
Start time: YYYY-MM-DD HH:MM (TZ)
Affected components: API, Dashboard, Payments
Impact: Qué ven los usuarios (errores, timeouts, rendimiento degradado) y quién está afectado
What we know: Una frase sobre la causa si está confirmada (evita especular)
What we’re doing: Acciones concretas (rollback, escalado, escalado con proveedor)
Next update: Hora en la que publicarás otra vez
Updates:
Los clientes no solo quieren información: quieren previsibilidad.
El mantenimiento programado debe sentirse tranquilo y estructurado. Estandariza los posts de mantenimiento con:
Mantén el lenguaje del mantenimiento específico (qué cambia, qué notarán los usuarios) y evita prometer de más —los clientes valoran la precisión sobre el optimismo.
Un historial de incidentes es más que un log: es una forma para que clientes (y tu equipo) entiendan con rapidez con qué frecuencia ocurren problemas, qué tipos de problemas se repiten y cómo respondéis.
Un historial claro genera confianza mediante la transparencia. También crea visibilidad de tendencias: si ves “latencia API” recurrente cada pocas semanas, es una señal para invertir en rendimiento (y priorizar revisiones post‑incidente). Con el tiempo, el reporte consistente puede reducir tickets porque los clientes se autosirven.
Elige una ventana de retención que encaje con las expectativas de tus clientes y la madurez del producto.
Sea lo que sea, indícalo claramente (por ejemplo: “Incident history is retained for 12 months”).
La consistencia facilita el escaneo. Usa un formato predecible como:
YYYY-MM-DD — Resumen corto (p. ej., “2025-10-14 — Entrega de email retrasada”)
Para cada incidente, muestra al menos:
Si publicas postmortems, enlaza desde el detalle del incidente al informe (por ejemplo: “Read the postmortem” enlazando a /blog/postmortems/2025-10-14-email-delays). Esto mantiene la línea temporal limpia y ofrece detalle para clientes que lo deseen.
Una página de estado ayuda cuando los clientes recuerdan consultarla. Las suscripciones lo cambian: los clientes reciben actualizaciones automáticamente, sin actualizar la página o escribir al soporte para confirmar.
La mayoría de equipos esperan al menos un par de opciones:
Si soportas varios canales, mantén el flujo de configuración consistente para que los clientes no sientan que se suscriben de cuatro formas distintas.
Las suscripciones deben ser siempre opt‑in. Sé explícito sobre lo que recibirán antes de confirmar—especialmente para SMS.
Da control a los suscriptores sobre:
Estas preferencias reducen la fatiga de alertas y mantienen la confianza en las notificaciones. Si no tienes suscripciones por componente todavía, empieza con “All updates” y añade filtrado más tarde.
Durante un incidente, el volumen de mensajes se dispara y los proveedores terceros pueden aplicar throttling. Verifica:
Vale la pena ejecutar una prueba programada (incluso trimestral) para asegurar que las suscripciones funcionan como es debido.
Añade un llamado claro a la suscripción en la página de estado —por encima del pliegue si es posible— para que los clientes se suscriban antes del próximo incidente. Hazlo visible en móvil e inclúyelo en lugares donde los clientes buscan ayuda (como un enlace desde tu portal de soporte o el /help center).
Elegir cómo construir tu página de estado no es tanto “¿podemos construirla?” sino qué quieres optimizar: rapidez de lanzamiento, fiabilidad durante incidentes y esfuerzo de mantenimiento.
Una herramienta alojada suele ser la ruta más rápida. Obtienes una página de estado lista, suscripciones, líneas de tiempo de incidentes y a menudo integraciones con sistemas de monitorización comunes.
Qué buscar en una herramienta alojada:
DIY puede ser buena si quieres control total sobre diseño, retención de datos y cómo se presenta el historial de incidentes. El intercambio es que tú eres responsable de la fiabilidad y operación.
Una arquitectura práctica DIY es:
Si te autoalojas, planifica modos de fallo: ¿qué pasa si tu base de datos principal está inaccesible o tu pipeline de deploy no funciona? Muchos equipos mantienen la página de estado en infraestructura separada (o incluso en un proveedor distinto) a la app principal.
Si quieres el control del DIY sin reconstruir todo, una plataforma de estilo “vibe‑coding” como Koder.ai puede ayudarte a levantar un sitio de estado personalizado (UI web más una pequeña API de incidentes) rápidamente desde una especificación guiada por chat. Eso es útil para equipos que quieren modelos de componente a medida, UX de historial personalizada o flujos administrativos internos—y poder exportar código, desplegar e iterar con rapidez.
Las herramientas alojadas tienen precios mensuales previsibles; DIY implica tiempo de ingeniería, costes de hosting/CDN y mantenimiento continuo. Si comparas opciones, plantea el gasto mensual esperado y el tiempo interno requerido—luego compáralo con vuestro presupuesto (ver /pricing).
Una página de estado solo es útil si refleja la realidad con rapidez. La forma más sencilla de lograrlo es conectar los sistemas que detectan problemas (monitorización) con los que coordinan la respuesta (workflow de incidentes), para que las actualizaciones sean coherentes y oportunas.
La mayoría de equipos combinan tres fuentes de datos:
Una regla práctica: la monitorización detecta; el workflow coordina; la página de estado comunica.
La automatización puede ahorrar minutos cuando importa:
Mantén el primer mensaje público conservador. “Investigating elevated errors” es más seguro que “Outage confirmed” cuando aún estás validando.
La mensajería totalmente automática puede fallar:
Usa la automatización para crear borradores y sugerencias, pero exige revisión humana para el lenguaje visible al cliente —especialmente en los estados Identified, Mitigated y Resolved.
Trata la página de estado como una bitácora visible al cliente. Asegura que puedas responder:
Esta pista de auditoría ayuda en la revisión post‑incidente, reduce la confusión durante los traspasos y genera confianza cuando los clientes piden aclaraciones.
Una página de estado solo ayuda si es accesible cuando tu producto no lo está. El fallo más común es construir la página de estado sobre la misma infraestructura que la app—entonces cuando la app cae, la página de estado desaparece también.
Siempre que sea posible, hospeda la página de estado en un proveedor diferente al de la app (o al menos en otra región/cuenta). El objetivo es separación del radio de explosión: una caída en la plataforma de la app no debería tirar también las comunicaciones de incidentes.
Considera también separar el DNS. Si el DNS de tu dominio principal está gestionado en el mismo lugar que el edge/CDN de tu app, un problema de DNS o certificado puede bloquear ambos a la vez. Muchos equipos usan un subdominio dedicado (por ejemplo, status.tuempresa.com) con DNS gestionado de forma independiente.
Mantén los assets ligeros: JavaScript mínimo, CSS comprimido y sin dependencias que requieran las APIs de tu app para renderizar. Pon un CDN delante y activa caché para recursos estáticos para que cargue incluso con mucho tráfico.
Una red de seguridad práctica es un modo estático de fallback:
Los clientes no deberían tener que iniciar sesión para ver la salud del servicio. Mantén la página de estado pública, pero protege las herramientas de administración/edición tras autenticación (SSO si lo tienes), con controles de acceso y logs de auditoría.
Finalmente, prueba escenarios de fallo: bloquea temporalmente tu origen de app en staging y confirma que la página de estado sigue resolviendo, carga rápido y puede actualizarse cuando más la necesitas.
Una página de estado solo genera confianza si se actualiza consistentemente durante incidentes reales. Esa consistencia no surge por accidente: necesitas propiedad clara, reglas sencillas y cadencia predecible.
Mantén el equipo central pequeño y explícito:
Si eres un equipo pequeño, una persona puede asumir dos roles—solo decídelo por adelantado. Documenta traspasos de roles y rutas de escalado en tu manual on‑call (ver /docs/on-call).
Cuando una alerta se convierte en incidente con impacto al cliente, sigue un flujo repetible:
Una regla práctica: publica la primera actualización dentro de 10–15 minutos, luego cada 30–60 minutos mientras dure el impacto —incluso si el mensaje es “Sin cambios, seguimos investigando.”
Dentro de 1–3 días hábiles, realiza una revisión post‑incidente ligera:
Luego actualiza la entrada del incidente con el resumen final para que el historial sea útil, no solo un registro de “resuelto”.
Una página de estado solo es útil si es fácil de encontrar, confiable y se actualiza consistentemente. Antes de anunciarla, haz un repaso “ready for production” —y luego establece una cadencia ligera para mejorarla con el tiempo.
Copy y estructura
Branding y confianza
Acceso y permisos
Prueba el flujo completo
Anunciar
Si construyes tu propio sitio de estado, considera ejecutar la misma checklist en staging primero. Herramientas como Koder.ai pueden acelerar este ciclo generando UI web, pantallas admin y endpoints backend desde una sola spec —y permitiéndote exportar el código y desplegar donde necesites.
Sigue unos pocos resultados simples y revísalos mensualmente:
Mantén una taxonomía básica para que el historial sea accionable:
Con el tiempo, pequeñas mejoras —redacción más clara, actualizaciones más rápidas, mejor categorización— se acumulan en menos interrupciones, menos tickets y más confianza del cliente.
Una página de estado SaaS es una página dedicada que muestra la salud actual del servicio y las actualizaciones de incidentes en un único lugar canónico. Importa porque reduce las consultas de “¿está caído?”, establece expectativas durante las interrupciones y genera confianza con comunicaciones claras y con marca temporal.
El estado en tiempo real responde “¿Puedo usar el producto ahora mismo?” con estados por componente.
El historial de incidentes responde “¿Con qué frecuencia ocurre esto?” con una línea temporal de incidentes pasados y mantenimientos.
Los postmortems responden “¿Por qué pasó y qué cambió?” con causa raíz y pasos de prevención (a menudo vinculados desde la entrada del incidente).
Empieza con 2–3 resultados medibles:
Escribe estos objetivos y revísalos mensualmente para que la página no quede obsoleta.
Asigna un propietario explícito y un respaldo (normalmente la rotación on‑call). Muchas equipes usan:
También define reglas por adelantado: quién puede publicar, si se requieren aprobaciones y la cadencia mínima de actualizaciones (por ejemplo, cada 30–60 minutos durante incidentes graves).
Elige componentes según cómo los describen los clientes, no por nombres internos. Componentes comunes incluyen:
Si la fiabilidad varía por región, divide por región (por ejemplo, “API – US” y “API – EU”).
Usa un conjunto pequeño y consistente de niveles y documenta criterios internos para cada uno:
La consistencia es más importante que la precisión perfecta. Los clientes deben aprender qué significa cada nivel por el uso repetido y predecible.
Una actualización práctica de incidente debe incluir siempre:
Incluso si no conoces la causa raíz, puedes comunicar alcance, impacto y qué haréis a continuación.
Publica una actualización inicial de “Investigating” rápidamente (normalmente dentro de 10–15 minutos tras confirmar el impacto). Luego:
Si no vas a cumplir la cadencia, publica una nota breve reajustando expectativas en lugar de quedarte en silencio.
Las herramientas alojadas optimizan rapidez y fiabilidad (a menudo permanecen en línea aunque vuestra app esté caída) e incluyen suscripciones e integraciones.
DIY ofrece control total, pero debes diseñar para la resiliencia:
Ofrece los canales que ya usan los clientes (normalmente email y SMS, más Slack/Teams o RSS). Mantén las suscripciones opt‑in y aclara:
Prueba entregabilidad y límites de tasa periódicamente para que las notificaciones sigan funcionando cuando el tráfico se dispare durante un incidente.
