Tu SaaS deja de funcionar a las 10:14. A las 10:16 tienes cuarenta conversaciones abiertas preguntando lo mismo: «¿está caído?», «¿es cosa mía?», «no me carga nada». Tu equipo, que debería estar arreglando el problema o explicándolo, está respondiendo uno a uno.
Una página de estado responde esa pregunta a todos a la vez, y es de las herramientas con mejor relación entre lo poco que cuesta montarla y lo mucho que ahorra el día que hace falta.
La respuesta corta
Una página de estado de un SaaS muestra si cada parte del servicio funciona, publica las incidencias con actualizaciones periódicas y guarda el historial. Debe tener pocos componentes que el cliente entienda —la aplicación, la API, las notificaciones, los pagos—, estados claros, mensajes escritos para el cliente y actualizaciones cada treinta o sesenta minutos durante una incidencia, aunque no haya novedades. Tiene que estar alojada fuera de tu infraestructura, para que no se caiga cuando se cae tu producto, y enlazada desde tu web, tu centro de ayuda y tus canales de soporte.
Qué componentes mostrar
Los que el cliente reconoce, no los de tu arquitectura:
| Bien | Mal |
|---|---|
| Aplicación web | Cluster de Kubernetes |
| App móvil | Base de datos principal |
| API | Load balancer |
| Notificaciones por correo | Servicio de colas |
| Integración con WhatsApp | Worker de tareas |
| Pagos | Proveedor de cobros |
Entre cuatro y ocho componentes. Más confunden; menos no dicen si lo que le falla al cliente es lo que está caído.
Qué estados usar
| Estado | Cuándo |
|---|---|
| Operativo | Todo funciona |
| Rendimiento degradado | Funciona, pero lento o con errores ocasionales |
| Caída parcial | Una parte no funciona para algunos clientes |
| Caída total | No funciona para nadie |
| Mantenimiento | Parada programada y avisada |
Cómo escribir las actualizaciones
Una incidencia se cuenta en fases, cada una con un mensaje corto:
10:22 — Investigando. Algunos clientes no pueden iniciar sesión en la aplicación web. Lo estamos investigando. La app móvil y la API funcionan con normalidad. Próxima actualización a las 10:50.
10:48 — Identificado. El problema está en el servicio de inicio de sesión tras el cambio de esta mañana. Estamos revirtiéndolo. Próxima actualización a las 11:20.
11:05 — Resuelto. El inicio de sesión funciona con normalidad desde las 11:02. Si sigues sin poder entrar, cierra sesión y vuelve a entrar. Publicaremos un análisis de lo ocurrido en las próximas 48 horas.
Reglas que se repiten:
- Qué notan los clientes, no qué ha fallado por dentro.
- Qué funciona, además de qué no.
- La hora de la próxima actualización, siempre, y cumplirla aunque no haya novedades.
- Sin optimismo prematuro: «resuelto» solo cuando lo está.
Cómo comunicar una incidencia más allá de la página de estado —por correo, en la aplicación, con los clientes grandes— está en cómo comunicar una incidencia a tus clientes.
Dónde alojarla
Fuera de tu infraestructura. Si tu página de estado vive en los mismos servidores que tu producto, el día que se cae el producto se cae también la página que debería explicarlo. Lo habitual es un subdominio propio (por ejemplo, estado.tuproducto.com) servido por un proveedor distinto.
Qué herramientas hay
- Servicios dedicados de pago, como Atlassian Statuspage, Instatus o Better Stack, que incluyen suscripciones por correo, componentes e historial.
- Opciones de código abierto que puedes alojar tú, como Upptime o Cachet.
- Una página sencilla alojada aparte, si estás empezando. Mejor algo simple y actualizado que una herramienta completa que nadie mantiene.
Lo que conviene que tenga: que los clientes puedan suscribirse a avisos, un historial de incidencias y que se pueda actualizar desde el móvil.
Dónde enlazarla
- En el pie de tu web y en el centro de ayuda.
- En la respuesta automática de tus canales de soporte durante una incidencia.
- En los mensajes de error del producto, cuando el error es vuestro. Más en mensajes de error que no generan tickets.
Quién la actualiza
Una persona concreta durante cada incidencia, distinta de quien arregla el problema. En una startup pequeña suele ser un fundador o la persona de soporte. Lo importante es que esté decidido antes de la primera incidencia, no durante.
Si atiende un agente de IA, que sepa dónde está la página de estado y que pueda remitir a ella: durante una caída, buena parte de las preguntas se resuelven con «estamos al tanto, aquí lo seguimos». Mejor aún si la incidencia está publicada como información que el agente puede consultar.
Preguntas frecuentes
¿Qué es una página de estado?
Una página pública que muestra si cada parte de un servicio funciona, publica las incidencias con sus actualizaciones y guarda el historial.
¿Necesita una startup una página de estado?
Sí, y cuanto más pequeño es el equipo, más: permite avisar a todos los clientes a la vez sin responder uno a uno.
¿Cada cuánto se actualiza durante una incidencia?
Cada treinta o sesenta minutos, según la gravedad, y siempre a la hora anunciada aunque no haya novedades.
¿Hay que publicar todas las incidencias?
Las que notan los clientes, sí. Esconderlas se descubre y quita credibilidad a la página.
¿Dónde debe estar alojada?
Fuera de tu infraestructura, para que siga funcionando cuando tu producto falla.
