Reintentos antes de alertar

¿Qué son los reintentos?

Los reintentos vuelven a ejecutar una comprobación fallida antes de enviarte una alerta. Una única petición fallida no siempre es una caída real: un corte breve de red, un arranque en frío lento o un tiempo de espera puntual pueden hacer fallar una comprobación aunque tu API esté sana. Los reintentos te permiten confirmar que un fallo es real antes de avisar a nadie.

Los reintentos solo se producen cuando una comprobación falla. Una comprobación correcta nunca se reintenta, así que esta opción no te cuesta nada mientras todo esté sano.

Los reintentos están disponibles para verificaciones de API, multipaso, TCP y DNS. Las verificaciones de navegador no reintentan; en su lugar alertan tras N fallos consecutivos, como se explica más abajo.

¿Por qué usar reintentos?

La razón principal es el ruido de las alertas. Sin reintentos, cada corte pasajero se convierte en una alerta, y las alertas que casi siempre son falsas acaban ignorándose. Con reintentos, solo te enteras de los fallos que han sobrevivido a varios intentos.

Las comprobaciones nuevas empiezan con 2 reintentos, lo que filtra los cortes pasajeros sin retrasar mucho una alerta real. Pon Reintentos en 0 para desactivar la función. Las comprobaciones existentes conservan el valor con el que se guardaron.

Los ajustes

Los ajustes están en la sección Reintentos antes de alertar del formulario de la verificación, en la página de nueva verificación de API.

Ajuste	Rango	Predeterminado	Qué hace
Reintentos	0 a 5	2	Cuántos intentos adicionales se hacen tras el primer fallo
Intervalo (s)	1 a 60	10	La espera base entre intentos
Backoff	Fijo, Lineal, Exponencial	Fijo	Cómo crece la espera con cada intento
Tiempo máximo de reintento (s)	1 a 300	60	Un presupuesto de tiempo total para toda la secuencia

Un reintento siempre se ejecuta desde la misma ubicación que el intento fallido.

Cómo funciona el backoff

El backoff decide cuánto esperamos antes de cada reintento, partiendo de tu Intervalo. Para un intervalo de 10 segundos:

Intento	Fijo	Lineal	Exponencial
1.er reintento	10s	10s	10s
2.º reintento	10s	20s	20s
3.er reintento	10s	30s	40s

• Fijo espera el mismo intervalo cada vez. Úsalo cuando esperes que un fallo se resuelva rápido.
• Lineal hace crecer la espera de forma constante. Un término medio razonable.
• Exponencial duplica la espera cada vez. Úsalo cuando un servicio con dificultades necesite margen para recuperarse y no quieras que tus reintentos añadan carga.

Tiempo máximo de reintento

El tiempo máximo de reintento es un presupuesto para toda la secuencia, medido desde el inicio del primer intento. Antes de cada espera, comprobamos si esa espera llevaría la secuencia más allá del presupuesto. Si es así, paramos e informamos del último fallo.

Esto significa que el presupuesto puede terminar tus reintentos antes de haberlos usado todos, y es intencionado. Por ejemplo, con un intervalo de 10 segundos, backoff Exponencial, 3 reintentos y un presupuesto de 60 segundos, el tercer reintento necesitaría una espera de 40 segundos además de los aproximadamente 30 segundos ya consumidos. Eso supera el presupuesto, así que la comprobación se detiene tras el segundo reintento.

Si quieres que se ejecuten todos tus reintentos, asegúrate de que el presupuesto sea mayor que la suma de las esperas anteriores.

Qué se registra

Solo se guarda el último intento como resultado de la comprobación. Esto es lo que hace útiles a los reintentos:

• Falla y luego pasa en un reintento: la comprobación se registra como correcta y no se envía ninguna alerta. El corte pasajero nunca te llega.
• Falla en todos los intentos: la comprobación se registra como fallida y tus canales de alerta se activan como siempre.

Como solo se almacena el resultado final, los reintentos no distorsionan tus cifras de disponibilidad con cortes pasajeros.

Verificaciones de navegador: alertar tras N fallos consecutivos

Las verificaciones de navegador no reintentan. En la misma sección el campo pasa a ser Alert after N consecutive failures, y la frecuencia de tu verificación es el espaciado entre ejecuciones. LoadFocus alerta cuando se producen N ejecuciones fallidas seguidas, de 0 a 5. Un valor de 0 o 1 alerta en la primera ejecución fallida.

Una notificación de recuperación solo se envía cuando se envió una alerta, así que un fallo breve que nunca llegó a N no produce un mensaje de "recuperado".

Alertar en cada fallo

En Advanced notification options, el interruptor cada vez que una verificación falla envía una alerta por cada ejecución fallida, en lugar de solo cuando la verificación empieza a fallar. En una verificación de navegador con N mayor que 1, empieza a alertar cuando se alcanzan N ejecuciones fallidas seguidas y después alerta en cada ejecución fallida adicional. seguir recordándome mientras una comprobación siga caída envía recordatorios repetidos con la programación que elijas.

Alertar solo cuando fallan varias ubicaciones

Por defecto, una sola ubicación con fallo marca toda la ejecución como fallida. Una verificación definida en un archivo YAML con Monitoring as Code puede fijar locationFailureThreshold en un número N mayor que 1: entonces solo alerta cuando fallan al menos N ubicaciones en la misma ejecución.

Casos de uso prácticos

• APIs públicas a través de internet: 1 o 2 reintentos con backoff Fijo y un intervalo corto filtran el ruido de red habitual.
• Servicios con arranque en frío: usa backoff Lineal o Exponencial para que una primera respuesta lenta tenga tiempo de calentarse.
• Un servicio bajo carga: usa backoff Exponencial para que tus reintentos le den margen en lugar de añadir presión.
• Comprobaciones críticas que deben alertar de inmediato: pon Reintentos en 0 para que un solo fallo avise al momento.

Una nota sobre la frecuencia

Mantén tu presupuesto de reintentos por debajo de la frecuencia de la verificación. Si una verificación se ejecuta cada minuto y tus reintentos pueden prolongarse más de un minuto, una verificación fallida seguiría reintentando cuando toque su siguiente ejecución.

Guías relacionadas

• Cómo crear una nueva verificación de API para los ajustes comunes de las verificaciones
• Canales de alerta para elegir dónde se entregan las alertas
• Monitoreo de uptime