Monitoreo de disponibilidad para SaaS — se entera antes del primer ticket.
Uptimia comprueba por separado su API pública, su flujo de inicio de sesión y la tarea de facturación de anoche, 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 mire su equipo.
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 le 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 que investigar en su bandeja de entrada.
«Estamos en AWS — la disponibilidad es cosa suya».
El SLA de AWS cubre su infraestructura, no su producto. Un despliegue fallido, un certificado caducado o un worker de colas atascado le tocan a usted — y la página de estado del proveedor sigue en verde en 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 dijo antes de que preguntara. Un cliente que no encuentra nada da por hecho que usted tampoco lo sabe.
«Tres nueves es prácticamente perfecto» es la más extendida. Un 99,9 % de disponibilidad permite 43 minutos de tiempo de inactividad al mes. En una web corporativa eso es un error de redondeo — pero los clientes trabajan dentro de un SaaS. Multiplique esos 43 minutos por 500 clientes: 21.500 minutos-cliente, 358 horas al mes en las que alguien se encuentra su producto roto.
Las renovaciones no las decide su 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
Cada capa de su producto, vigilada
Las comprobaciones llegan a su API y a sus páginas, un navegador real reproduce el inicio de sesión y el registro, sus 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.
Hecho para los fallos de SaaS
La API que llaman sus clientes
Que la página de inicio cargue no dice nada del endpoint que usan sus integraciones — así que hoy se entera por un cliente. En su lugar, Uptimia ejecuta una cadena de solicitudes reales contra su API pública, hasta cada minuto: inicia sesión, obtiene 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 sus 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, hace 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: su 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
- Usted decide 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 su dominio
Antes de abrir un ticket, un cliente busca una página que diga que ya lo sabe. Ponga una en su propio dominio — con su 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 electrónico en cada actualización.
- Su dominio, SSL automático —
status.tuapp.compor HTTPS, con el distintivo «Con la tecnología de Uptimia» opcional - Secciones y suscriptores — agrupe monitores por área, publique actualizaciones de incidentes y mantenimiento, avise a los suscriptores
- Pública o privada — abierta a sus clientes, o protegida con contraseña
Un incidente, su equipo y su página de estado
El mismo incidente confirmado avisa a quien esté de guardia y actualiza la página que sus clientes ya están recargando.
Microsoft Teams12 canales de alertas, una sola lista de contactos — y la página de estado que vigilan sus clientes, actualizada desde el mismo incidente.
Explore el directorio completo de integraciones →Una interrupción debería avisarle.No a sus 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.
Configure el monitoreo de su SaaS en tres pasos
Las rutas críticas de su producto pueden estar bajo vigilancia esta misma tarde.
Apunte las comprobaciones a su producto
Agregue una comprobación de disponibilidad en la aplicación, una cadena de solicitudes contra su API pública y una reproducción del inicio de sesión en un navegador real.
Conecte heartbeats a sus tareas
Coloque 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…
Enrute las alertas y publique el estado
Envíe alertas a Slack y PagerDuty, elija a quién se avisa después si nadie lo reconoce, y publique la disponibilidad y los flujos en una página de estado.
También incluido
Observe lo que sienten los usuarios reales
Un snippet pasivo de JavaScript informa de los tiempos de carga de los usuarios reales, por dispositivo, navegador y ubicación.
Automatice desde la API
Cree monitores y páginas de estado desde sus propias herramientas — ponga en marcha comprobaciones desde un script de despliegue.
Ventanas de mantenimiento
¿Va a lanzar una versión? Programe 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
Rastree una redirección encabezado por encabezado con el HTTP Status Checker, o mire qué permite cada «nueve» con la Uptime Calculator.
¿Qué es el monitoreo de disponibilidad para SaaS?
El monitoreo 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 su equipo reciba una alerta en el momento en que algo se rompe. El ping de la página de inicio sigue en verde mientras su API deja de responder, el inicio de sesión falla o una tarea nocturna se detiene.
En verde mientras los clientes están atascados
Su comprobación pasa mientras aquello por lo que pagan los clientes está caído — se entera por un ticket.
Usted vigila 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 convierte en minutos — esto es lo que permite cada nivel.
Abra 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 monitoreo para SaaS
01¿Qué es el monitoreo de disponibilidad para SaaS?+
02¿En qué se diferencia esto de simplemente hacer ping a mi página de inicio?+
03¿Puedo monitorear 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¿Admiten SSO y puedo obtener informes de SLA?+
10¿Qué canales de alertas puede usar mi equipo?+
11¿Necesito instalar algo en mi aplicación?+
curl a la URL de ping); el monitoreo de usuarios reales es un pequeño snippet de JavaScript. No hace falta ningún agente, salvo que también quiera métricas del servidor.Su API, sus flujos y sus tareas, bajo vigilancia
Ponga su API, su flujo de inicio de sesión y sus tareas en segundo plano bajo vigilancia esta misma tarde — y deje de enterarse de las interrupciones por sus clientes.