Monitorización de disponibilidad para SaaS — te enteras antes del primer ticket.
Uptimia le da a tu API pública, a tu flujo de inicio de sesión y a la tarea de facturación de anoche una comprobación propia a cada uno, en lugar de adivinar a partir de una página de inicio que sigue cargando. Un fallo se confirma desde más de una región antes de avisar a quien esté de guardia — en Slack, PagerDuty o donde sea que tu equipo lo mire.
Step breakdown
All 2 steps passedFailed at step 2244 ms · 02:13236 ms · 02:147-day averagesLast runAssertions — step 2
3 of 3 passing0 of 3 passedResponse — step 2
200 · 96 ms502 · 84 msRecent Runs
every minute · rotating locations
New York✗ Failed at step 20.24 s
Frankfurt✗ Failed at step 20.24 s
London✓ All 2 steps passed0.25 s
Sydney✓ All 2 steps passed0.26 s
Amsterdam✓ All 2 steps passed0.23 sNew York✓ All 2 steps passed0.24 s
Tokyo✓ All 2 steps passed0.25 sCuatro creencias que hacen perder clientes de SaaS
Cada una suena razonable — y cada una deja que un fallo siga activo hasta que lo descubre un cliente.
«Si algo se rompiera, los clientes nos avisarían».
Los que te avisan son los más fieles. Un cliente potencial que se topa con un registro roto cierra la pestaña y nunca llega a ser cliente — no hay nadie que se queje, ni nada en tu bandeja de entrada que investigar.
«Estamos en AWS — la disponibilidad es cosa suya».
Su SLA cubre su infraestructura, no tu producto. Un despliegue fallido, un certificado caducado o un worker de colas atascado son cosa tuya — y la página de estado del proveedor sigue en verde durante todos y cada uno de ellos.
«La aplicación carga, así que estamos operativos».
Un SaaS es un conjunto de funcionalidades, no una sola página. El panel puede cargar mientras la API pública deja de responder, el inicio de sesión falla o la tarea de facturación se salta una noche sin hacer ruido — cada cosa falla por su cuenta, y «estar operativos» las esconde todas.
«Admitir incidentes en público nos hace quedar mal».
El silencio queda peor. Un cliente que encuentra una nota de estado no abre ningún ticket — y recuerda que se lo dijiste antes de que preguntara. Un cliente que no encuentra nada da por hecho que tú tampoco lo sabes.
«Tres nueves es prácticamente perfecto» es la más extendida. Un 99,9 % de disponibilidad permite 43 minutos de caída al mes. En una web corporativa eso es un error de redondeo — pero los clientes trabajan dentro de un SaaS. Multiplica esos 43 minutos por 500 clientes: 21.500 minutos-cliente, 358 horas al mes en las que alguien se encuentra tu producto roto.
Las renovaciones no las decide tu porcentaje de disponibilidad. Las decide quién se enteró primero, y lo rápido que se solucionó.
Así es como se ve ese fallo cuando una cadena está vigilando el endpoint.↓ minuto a minuto
Una interrupción de API, de principio a fin
El endpoint de cuenta dejó de funcionar. El panel seguía cargando, el ping de la página de inicio seguía en verde, y todas las integraciones que llamaban a ese endpoint ya estaban fallando.
Con eso la API queda cubierta. Pero un SaaS se rompe en cuatro capas — aplicación, API, flujos, tareas — y cada una falla por su cuenta.↓ cada capa
Todas las capas de tu producto, vigiladas
Las comprobaciones llegan a tu API y a tus páginas, un navegador real reproduce el inicio de sesión y el registro, tus tareas envían su ping, y un snippet informa de lo que ven los usuarios reales — todo en un mismo panel, con una sola lista de contactos.
Pensado para cómo se rompe un SaaS
La API que llaman tus clientes
Que la página de inicio cargue no dice nada del endpoint que usan sus integraciones — así que hoy te enteras por un cliente. En su lugar, Uptimia ejecuta una cadena de solicitudes reales contra tu API pública, hasta cada minuto: inicia sesión, obtén el token, llama al endpoint protegido, lee la respuesta.
- Cadenas de hasta 15 pasos — cada paso comprueba la respuesta que recibe y le pasa lo que necesita al siguiente
- Inicia sesión primero — accede y luego llama a los endpoints a los que solo puede llegar un cliente autenticado
- Confirmado, no inestable — un paso que falla se comprueba desde hasta tres ubicaciones antes de abrir un incidente
Inicio de sesión y registro, probados antes que tus clientes
Después de un despliegue, la primera persona en intentar iniciar sesión debería ser un robot. Uptimia reproduce el inicio de sesión y el registro en un navegador real desde 13 ubicaciones, hasta cada 10 minutos, y abre un incidente en el momento en que falla un paso — con una captura de pantalla de cómo estaba la página cuando se rompió.
- Un navegador real — entra en la página, rellena los campos, haz clic, comprueba qué aparece
- Captura al fallar — la cascada muestra el paso que falló y cómo se veía la página
- Tiempos por paso — duraciones de cada paso, para que un flujo que se ralentiza se note antes de fallar
La tarea de facturación que nunca se ejecutó
Un cron que muere no lo anuncia — nada parece «caído» desde fuera mientras las facturas dejan de enviarse en silencio. Los heartbeats le dan la vuelta a esto: tu tarea hace ping a Uptimia cuando termina, y un ping que no llega es el incidente.
- Una única URL de ping — una línea al final de un cron, worker o script de backup
- Tú decides cuándo toca — una programación y un periodo de gracia; un ping que nunca llega abre el incidente
- También señales de inicio y de fallo — detecta una tarea que empezó pero nunca terminó, o que reportó su propio fallo
Una página de estado en tu dominio
Antes de abrir un ticket, un cliente busca una página que diga que ya lo sabes. Pon una en tu propio dominio — con tu logo, el distintivo de Uptimia desactivado — mostrando el estado en vivo, 90 días de histórico y todas las notas de incidentes, con los suscriptores avisados por correo en cada actualización.
- Tu dominio, SSL automático —
status.tuapp.compor HTTPS, con el distintivo «Con la tecnología de Uptimia» opcional - Secciones y suscriptores — agrupa monitores por área, publica actualizaciones de incidentes y mantenimiento, avisa a los suscriptores
- Pública o privada — abierta a tus clientes, o protegida con contraseña
Un incidente, tu equipo y tu página de estado
El mismo incidente confirmado avisa a quien esté de guardia y actualiza la página que tus clientes ya están recargando.
Microsoft Teams12 canales de alerta, una sola lista de contactos — y la página de estado que vigilan tus clientes, actualizada desde el mismo incidente.
Explora el directorio completo de integraciones →Una interrupción debería avisarte a ti.No a tus clientes.
La prueba de 30 días abre todos los tipos de monitor — cadenas de API, flujos de inicio de sesión, heartbeats y comprobaciones de disponibilidad.
Configura la monitorización de tu SaaS en tres pasos
Las rutas críticas de tu producto pueden estar bajo vigilancia esta misma tarde.
Apunta las comprobaciones a tu producto
Añade una comprobación de disponibilidad en la aplicación, una cadena de solicitudes contra tu API pública y una reproducción del inicio de sesión en un navegador real.
Conecta heartbeats a tus tareas
Coloca la URL de ping al final de cada cron, worker o backup — un ping que no llega se convierte en un incidente.
curl -fsS uptimia.com/p/hb_9f3c…
Enruta las alertas y publica el estado
Envía alertas a Slack y PagerDuty, elige a quién se avisa después si nadie lo reconoce, y publica la disponibilidad y los flujos en una página de estado.
También incluido
Observa lo que sienten los usuarios reales
Un snippet pasivo de JavaScript informa de los tiempos de carga de los visitantes reales, por dispositivo, navegador y ubicación.
Automatiza desde la API
Crea monitores y páginas de estado desde tus propias herramientas — pon en marcha comprobaciones desde un script de despliegue.
Ventanas de mantenimiento
¿Vas a lanzar una versión? Programa la ventana — las comprobaciones se pausan, las alertas guardan silencio y la página de estado muestra el trabajo planificado.
Un incidente, una alerta
Una tormenta de avisos se convierte en un único resumen, no en cien pings — con un enlace firmado para reconocerlo y el MTTA registrado.
Avisos de recuperación
Cuando la API vuelve, los ingenieros a los que se avisó también reciben el aviso de que todo está resuelto.
Herramientas gratuitas para depurar después
Rastrea una redirección cabecera por cabecera con el HTTP Status Checker, o mira qué permite cada «nueve» con la Uptime Calculator.
¿Qué es la monitorización de disponibilidad para SaaS?
La monitorización de disponibilidad para SaaS consiste en vigilar las partes de un producto de las que dependen los clientes — la API pública, los flujos de inicio de sesión y registro, y las tareas en segundo plano que hay detrás — para que tu equipo reciba una alerta en el momento en que algo se rompe. El ping de la página de inicio sigue en verde mientras tu API deja de responder, el inicio de sesión falla o una tarea nocturna se detiene.
En verde mientras los clientes están atascados
Tu comprobación pasa mientras aquello por lo que pagan los clientes está caído — te enteras por un ticket.
Vigilas cada capa
Las comprobaciones de API, flujos y tareas alimentan un único canal — el fallo llega a un ingeniero, no a un cliente.
Cuánto tiempo de inactividad permite cada «nueve»
«99,9 % de disponibilidad» suena infalible hasta que lo conviertes en minutos — esto es lo que permite cada nivel.
Abre la calculadora de disponibilidad →| Disponibilidad | Tiempo de inactividad / mes | Tiempo de inactividad / año |
|---|---|---|
| 99% | 7h 18m | 3d 15h |
| 99.9% | 43m 49s | 8h 46m |
| 99.95% | 21m 54s | 4h 23m |
| 99.99% | 4m 23s | 52m 35s |
| 99.999% | 26s | 5m 15s |
Preguntas frecuentes sobre monitorización para SaaS
01¿Qué es la monitorización de disponibilidad para SaaS?+
02¿En qué se diferencia esto de simplemente hacer ping a mi página de inicio?+
03¿Puedo monitorizar mi API pública?+
{{variable}} entre pasos. Se ejecuta hasta cada minuto en todos los planes, y un paso que falla se vuelve a ejecutar desde hasta tres ubicaciones antes de abrir un incidente. Una cadena es la comprobación más pesada de ejecutar, así que los monitores de API tienen su propio límite por plan — los números están en la página de precios.04¿Puede detectar un inicio de sesión o un registro roto?+
05¿Puedo recibir una alerta cuando una tarea en segundo plano se detiene?+
06¿Con qué rapidez puede comprobar?+
07¿Puedo ofrecer a mis clientes una página de estado?+
08¿Puedo restringir a un compañero de equipo a solo algunos monitores?+
09¿Admitís SSO y puedo obtener informes de SLA?+
10¿Qué canales de alerta puede usar mi equipo?+
11¿Necesito instalar algo en mi aplicación?+
curl a la URL de ping); la monitorización de usuarios reales es un pequeño snippet de JavaScript. No hace falta ningún agente, salvo que también quieras métricas del servidor.Tu API, tus flujos y tus tareas, bajo vigilancia
Pon tu API, tu flujo de inicio de sesión y tus tareas en segundo plano bajo vigilancia esta misma tarde — y deja de enterarte de las interrupciones por tus clientes.