Alertas de interrupciones: 3 comprobaciones sencillas para detectar fallos tempranos

Por qué estas tres alertas detectan la mayoría de las interrupciones tempranas

La mayoría de las interrupciones las descubren primero los clientes, no tu equipo. Alguien intenta cargar tu sitio, no puede registrarse o paga y nunca recibe acceso. Para cuando llegan los correos de soporte o alguien nota que cae la facturación, ya estás en medio de un incidente.

“Temprano” suele significar los primeros 5 a 30 minutos. Ahí un problema pequeño aún es fácil de revertir: revertir un despliegue, reiniciar un worker atascado, renovar un secreto caducado o arreglar una mala configuración antes de que cientos de usuarios lo noten.

Por eso menos alertas a menudo vencen a una lista larga y ruidosa. Si tienes diez monitores que disparan todo el tiempo, la gente deja de confiar en ellos. Un pequeño conjunto de señales que casi siempre significan algo obtiene atención rápido, incluso a las 2 a. m.

Estas tres comprobaciones cubren las formas más comunes en que un producto falla en el mundo real:

• ¿Puede alguien acceder al sitio en absoluto?
• ¿Puede un nuevo usuario completar el registro?
• ¿Fluyen el dinero y los eventos de cumplimiento (pagos y webhooks)?

En conjunto forman una red de seguridad simple: “puerta principal, crecimiento, ingresos”. Si cualquiera de ellas falla, probablemente tienes una interrupción que sienten los usuarios.

Lo que no cubren: rendimiento lento, errores parciales en funciones tras iniciar sesión, problemas de corrección de datos y problemas de “funciona en EE. UU. pero no en Europa”. Tampoco detectarán fallos silenciosos como un job en background que acumula trabajo antes de afectar a los registros.

Un ejemplo concreto: un despliegue rompe accidentalmente una variable de entorno. La página principal puede seguir cargando, pero las peticiones de registro comienzan a fallar y los webhooks de pago dejan de procesarse. Con solo estas alertas, lo encuentras en minutos en vez de esperar una queja.

Alerta 1: Sitio caído (chequeo simple de disponibilidad)

Si solo configuras una alerta, que sea un chequeo de disponibilidad que responda a una pregunta: ¿puede una persona real cargar tu producto ahora mismo?

Una configuración práctica usa tres objetivos. Comprueba tu página principal para captar fallos de DNS, CDN y hosting básico. Comprueba una página app shell (una ruta de la app para usuarios no autenticados que carga JavaScript y CSS) para detectar builds rotos y problemas de assets. Luego comprueba un endpoint de salud de la API ligero que devuelva rápido un 200 con una carga mínima, que detecta caídas del backend incluso cuando la página principal sigue cargando.

Los chequeos de uptime pueden engañar si dependes de una sola ubicación. Usa al menos dos regiones (o dos chequeos independientes) y trata el sitio como “caído” solo cuando ambos fallen en la misma ventana corta. Eso evita llamar a alguien porque un data center o ISP tuvo un percance.

Cuando una alerta se dispare, debe ser inmediatamente accionable. Incluye la URL exacta que falló, hora del primer fallo y hora del fallo más reciente, dónde falló (región/ubicación), qué tipo de fallo fue (código de estado, timeout, DNS, TLS) y la última vez conocida de éxito.

Para decidir entre llamar o solo notificar por chat, mantén una regla simple. Haz página cuando el app shell o el endpoint de salud de la API fallen dos veces seguidas (por ejemplo, en 2–3 minutos). Envía solo chat por un único chequeo fallido, o por una falla en la página principal cuando el app shell aún funcione.

Alerta 2: Fallo en registros (tu crecimiento se detiene en silencio)

Si tu sitio está arriba pero la gente no puede crear cuentas, puedes perder un día entero de crecimiento sin notarlo. Monitorizar registros es una de las alertas de mayor valor que puedes añadir.

Elige un camino crítico y pruébalo de extremo a extremo: abre la página de registro, envía el formulario, verifica que se creó el usuario y confirma que la app puede iniciar sesión (o que se alcanza el paso de “revisa tu correo” si usas verificación por email). La idea es captar fallos reales, no solo “la página devolvió 200 OK”.

Qué monitorizar (mantente enfocado en resultados)

Apunta a unas pocas señales que reflejen cómo funciona realmente el flujo. Vigila la tasa de éxito del recorrido completo de registro, más las tasas de error y latencia de los endpoints de registro y login. Añade una salva de negocio: alerta si el recuento de nuevos usuarios cae a cero (o casi cero) en una ventana que tenga sentido para tu tráfico.

Esa salva es importante porque algunos fallos pasan por alto las comprobaciones sintéticas. Un endpoint puede aún devolver “éxito”, pero la entrega de correo falla, o un país queda bloqueado, y los registros reales se detienen en silencio.

Configura la alerta para dispararse por fallos sostenidos, no por un solo destello. Para muchos productos, “3 checks de registro fallidos en 5 minutos” es un disparador más sólido que un único fallo.

Alerta 3: Pagos o webhooks fallando (dinero y cumplimiento)

Los pagos son donde los errores pequeños se convierten rápido en daño real. Esta alerta trata menos de “¿está arriba el sitio?” y más de “¿recibimos el dinero y entregamos lo prometido?”.

Suelen aparecer dos puntos de fallo. El primero es la creación del checkout/pago que falla (mala config, redirects rotos, problemas con el proveedor). El segundo es el manejo de webhooks: el pago se realiza pero tu app nunca procesa el evento que concede acceso, aplica crédito, inicia el cumplimiento o envía confirmación.

Una señal fuerte es directa: monitoriza la tasa de éxito del procesamiento de webhooks y la antigüedad del backlog. Si los eventos se acumulan, algo está atascado aunque los clientes sigan pudiendo pagar. Si la tasa de éxito baja, el handler está fallando, la verificación de firma se rompió o un despliegue cambió el parsing de la carga.

Mantén la monitorización vinculada a resultados. Los eventos de éxito de pago y las concesiones de derechos deben mantenerse alineados. Vigila reintentos repetidos de webhook, aumento de respuestas 4xx/5xx y la edad del evento no procesado más antiguo. Si tienes un canal de soporte, los informes de “pagado pero sin acceso” son una señal secundaria útil.

Si tu proveedor lo permite, añade un canario programado en un entorno seguro para confirmar todo el camino: crear pago, recibir webhook, conceder derecho, enviar confirmación.

Cómo configurar estas alertas paso a paso

Piensa como un usuario primerizo. El objetivo no es monitorizarlo todo. Es detectar fallos tempranos con tres comprobaciones pequeñas y repetibles.

1) Define las acciones exactas que vas a simular

Anota las acciones más pequeñas que prueban que tu producto sigue funcionando: cargar la página principal, crear una cuenta y completar el bucle de pago o webhook. Sé específico (por ejemplo, “enviar formulario de registro con un correo nuevo”), porque las comprobaciones vagas son difíciles de automatizar y fáciles de malinterpretar durante un incidente.

2) Mantén cada alerta mínima: 1–2 endpoints

Para cada alerta, elige un endpoint primario y una señal de respaldo si hace falta. “Sitio caído” puede ser el app shell más un endpoint de salud ligero. “Registros fallando” puede ser el POST de registro más una comprobación rápida de que existe el registro en la base de datos. “Pagos/webhooks” puede ser un endpoint de recepción de webhooks más una comprobación de que el cumplimiento se inició.

3) Programa y reintentos para reducir falsas alarmas

Ejecuta chequeos lo bastante seguido para notar problemas rápido (cada 1–5 minutos es común), pero reintenta antes de alertar. Un patrón sencillo es 2–3 intentos en 1–2 minutos y alertar solo si todos fallan. Configura timeouts para que servicios lentos generen advertencias antes de convertirse en caídas completas.

4) Decide quién recibe la notificación y cómo

Elige un responsable por alerta para que no sea “alguien lo hará”. Notifica primero a la persona on-call y envía copia a un canal compartido para que otros puedan ayudar si el incidente se prolonga.

5) Añade un runbook de una línea a cada alerta

Incluye la primera acción dentro del mensaje de la alerta:

• Sitio caído: comprueba el estado del hosting y el último despliegue, y revierte si es necesario.
• Registros fallando: intenta un registro manual, luego revisa logs del proveedor de auth y escrituras en la base de datos.
• Pagos/webhooks fallando: confirma el estado del proveedor, luego inspecciona logs de webhooks y la cola/backlog.

Umbrales, tiempos y quién recibe la página

Las buenas alertas son rápidas, pero no nerviosas. Quieres detectar fallos reales temprano sin despertar a alguien por un fallo de un minuto.

Umbrales sencillos para empezar (valores por defecto seguros)

Empieza aquí y ajústalo cuando tengas datos reales por una semana:

• Sitio caído (uptime): comprobar cada 1 minuto, hacer página tras 2 chequeos fallidos seguidos, preferiblemente desde 2 ubicaciones.
• Registros fallando: ejecutar un test sintético de registro cada 5 minutos, advertir tras 2 fallos consecutivos, y hacer página tras 3 fallos (unos 15 minutos aprox.).
• Pagos/webhooks fallando: advertir si la tasa de fallos es > 2% durante 10 minutos (o 10 fallos en 5 minutos); hacer página si la tasa es > 5% durante 10 minutos o cualquier serie sostenida de fallos graves.

Estos números no son mágicos. Son un buen punto de partida para que las alertas sean útiles desde el primer día.

Usa la regla de “dos golpes” para reducir ruido

La mayoría de equipos se inunda porque alerta con el primer error. Un arreglo simple es exigir confirmación.

Ejemplo: si tu chequeo de uptime falla una vez, envía una advertencia. Si falla dos veces seguidas, haz página al on-call.

Enruta alertas al propietario correcto

Quien reciba la página debe ser quien pueda arreglarlo más rápido:

• Sitio caído: on-call de ingeniería (backend o infra).
• Registros fallando: on-call de backend, y producto como advertencia.
• Pagos/webhooks fallando: on-call de backend, y propietario de pagos como advertencia.

Si estas alertas disparan constantemente, no las silencies. Trátalo como una señal de que un camino crítico es frágil y necesita trabajo.

Haz las alertas accionables (qué debe contener el mensaje)

Una alerta solo es útil si alguien puede dar un primer paso en menos de un minuto. La mayoría de malas alertas dicen qué falló, pero no qué hacer a continuación ni quién lo posee.

Mantén la carga consistente entre las tres comprobaciones para que cada alerta lea como un ticket mínimo de incidente. Como mínimo, incluye: qué falló (y el impacto en el usuario en palabras simples), dónde falló (entorno/región y URL exacta), cuándo empezó y cuánto tiempo lleva fallando, evidencia (código de estado, fragmento de error, ID de petición o trazado) y el propietario (servicio/equipo y rota de on-call).

Añade un poco de contexto que suele explicar incidentes rápido: versión y hora del despliegue actual, estado de flags relevantes, y cambios recientes de configuración como rotación de secretos, actualización de URL de webhook o cambios en la clave del proveedor de pagos.

Para instrucciones, sé breve: un paso de verificación, una posible primera solución (revertir o desactivar un flag nuevo) y una vía clara de escalado.

Comprobaciones rápidas: lista de 60 segundos para una interrupción

Cuando algo parece raro, no necesitas una investigación completa para confirmarlo. Necesitas una secuencia rápida que responda: ¿es alcanzable el sitio?, ¿puede un usuario nuevo unirse?, ¿siguen funcionando el dinero y los eventos de cumplimiento?

Ejecuta estos en orden:

• Confirma disponibilidad desde dos ubicaciones (una local y una remota). Si una falla y la otra pasa, sospecha de DNS o un problema regional.
• Crea un usuario de prueba y completa el flujo de registro, incluida la verificación por email si la usas.
• Dispara un evento de webhook (o una compra de prueba) y confirma que el procesamiento avanza. Busca un backlog que siga creciendo.
• Realiza un pago real pequeño de extremo a extremo y confirma que se concede acceso o que el pedido queda marcado como cumplido. Si el pago pasa pero el acceso no, los usuarios lo notarán rápido.
• Escanea señales clave: picos en 401/403, 500s o timeouts suelen apuntar a un despliegue malo, secreto expirado o auth mal configurada.

Si algún paso falla, pausa despliegues y revierte el cambio más reciente si puedes. Captura lo que viste (timestamp, endpoint, texto de error, ID de usuario u orden) para que quien lo arregle no vaya a ciegas.

Ejemplo: un mal despliegue y cómo ayudan las tres alertas

Un SaaS pequeño despliega un cambio “rápido” el viernes por la noche: un middleware nuevo que comprueba headers antes de que las peticiones lleguen a la app. Pasa las pruebas locales, se despliega y el equipo cierra los ordenadores.

Diez minutos después, llega la primera señal. No es un aluvión de logs, solo tres comprobaciones orientadas al usuario.

La comprobación de sitio falla primero: la página principal sigue cargando, pero rutas clave de la app devuelven 500s, así que el chequeo de disponibilidad lo atrapa. El chequeo de registro falla después: las cuentas dejan de crearse, confirmando que no es solo “baja de tráfico”. Entonces el chequeo de pagos/webhooks empieza a mostrar reintentos y crecimiento del backlog, revelando que los eventos de dinero no se están procesando.

En 15 minutos, el equipo lo acota comparando lo que sigue funcionando (páginas estáticas) con lo que falla (todo lo que pasa por el nuevo middleware). Detectan un requisito de header que bloquea callbacks de auth y solicitudes de proveedores de pago.

Revierten para restaurar registros y pagos, y luego envían un hotfix: permiten rutas de webhook y callbacks de auth conocidas, y registran las solicitudes bloqueadas con una razón clara. Después, cambian las comprobaciones de registro y webhook a cuentas canario y eventos de prueba para que los fallos sean fáciles de confirmar sin tocar clientes reales.

Errores comunes que hacen inútiles estas alertas

La forma más rápida de perder confianza en las alertas es hacerlas ruidosas, vagas o ciegas frente al dolor real del usuario. La mayoría de equipos no necesita más alertas. Necesitan menos alertas que apunten a una falla específica y den un paso claro a seguir.

Modos comunes de fallo:

• Solo comprobar “el servidor está arriba”. Un 200 OK en la página principal puede ocultar login roto, registro roto o un checkout atascado.
• Hacer página por cada error sin umbral. Un timeout es normal. Haz página por tasas sostenidas en una ventana corta.
• Asumir que la entrega de webhook significa éxito. Los proveedores pueden decir “entregado” aunque tu endpoint devuelva 500, haga timeout o pierda datos al parsear. Prueba recibir, validar, almacenar y disparar el siguiente paso.
• Ignorar la frecuencia de cambios en auth y secretos. Rotaciones de claves, apps OAuth caducadas y variables de entorno mal puestas pueden romper registros en silencio.
• Sin propietario y sin runbook. Si la alerta no dice quién la posee y cómo verificar la recuperación, se pierden los primeros 15 minutos.

Mantén el texto de la alerta práctico: qué falló, dónde (endpoint o flujo), cuántos usuarios afectan si puedes estimarlo y un paso de verificación.

Siguientes pasos: mantenlo simple y hazlo fiable

Si no haces nada más, mantén estas tres comprobaciones: sitio caído, registros fallando y pagos o webhooks fallando. Normalmente te avisan de un problema antes de que los usuarios llenen tu bandeja de entrada.

Después de eso, añade solo una alerta a la vez, y solo si puedes responder dos preguntas: qué acción tomarás cuando se dispare y con qué frecuencia debería dispararse en una semana normal. Si no puedes responder ambas, probablemente es ruido.

Una forma simple de mantener la confianza en las alertas es una prueba mensual de 10 minutos. Elige un momento tranquilo y fuerza cada alerta una vez para comprobar que sigue funcionando.

Si heredaste una base de código generada por IA y estas alertas siguen señalando los mismos puntos frágiles (auth, secretos, manejadores de webhook), suele ser más rápido arreglar el flujo subyacente que seguir afinando umbrales. FixMyMess (fixmymess.ai) se centra en diagnosticar y reparar esos caminos de producción para que tu monitorización se calme por la razón correcta: la app realmente resiste bajo tráfico real.