ForHosting KIT · Utilidades de desarrollo

Calcule una programación de espera exponencial para reintentos

Esta calculadora de espera exponencial convierte cuatro ajustes de reintento en una lista exacta de demoras.

● BetaGratis · en su navegador
Úselo desde WebAPIEmailTelegramApp pronto

Indique la espera antes del primer reintento, el multiplicador de crecimiento, la demora máxima permitida y el número de intentos. El resultado muestra cuánto esperar antes de cada reintento en la misma unidad temporal proporcionada. Sirve para revisar configuraciones, documentar clientes, comparar políticas y detectar ventanas de recuperación demasiado largas antes de llevar la lógica a producción.

Defina la política de reintentos con una unidad coherente

Comience con la demora base, es decir, la espera anterior al primer reintento. Elija una unidad compatible con su sistema, como milisegundos o segundos, y utilícela también para la demora máxima. La calculadora no impone una unidad porque la aritmética de la espera exponencial es igual en todas ellas. El multiplicador determina la rapidez con la que crece la demora sin limitar. Un valor de dos duplica cada espera sucesiva, mientras que uno mantiene un intervalo constante. Por último, «intentos» significa intentos de reejecución, no la operación inicial: si introduce cinco, recibirá cinco registros numerados del uno al cinco. Esta distinción evita errores frecuentes de desfase en manuales y revisiones. La demora base debe ser positiva, el multiplicador debe ser al menos uno, el máximo debe ser positivo y el número de intentos debe ser un entero entre uno y mil. Estas condiciones mantienen útil la programación y acotada la salida. Si su aplicación trabaja en milisegundos, identifique así los resultados copiados para evitar que después se interpreten como segundos.

Comprenda el crecimiento y el límite de demora máxima

Para el reintento n, la demora sin limitar equivale a la demora base multiplicada por el multiplicador elevado a n menos uno. El valor devuelto es el menor entre ese resultado y la demora máxima. Por ejemplo, una base de 250, un multiplicador de dos y un máximo de 2,000 producen 250, 500, 1,000, 2,000 y luego 2,000 en los intentos posteriores. El límite se aplica incluso cuando es inferior a la base; por ello, una base de diez y un máximo de tres devuelven tres desde el principio. Este comportamiento respeta un máximo estricto y deja visibles las configuraciones inusuales. La implementación avanza de forma iterativa, sin depender de un exponente ilimitado, y detiene el crecimiento al alcanzar el máximo. Así, los multiplicadores muy grandes siguen siendo deterministas sin introducir un valor infinito en el resultado JSON. La programación no incorpora variación aleatoria. Es una decisión deliberada: muestra la política determinista subyacente que la variación modificaría y permite usar el resultado en pruebas, documentación y comparaciones. Añada la variación por separado según las reglas exactas de su biblioteca cliente.

Aplique la programación sin provocar una avalancha de reintentos

Utilice el resultado para revisar el margen temporal antes de publicar una política. Una demora base corta puede parecer inocua, pero un multiplicador alto lleva rápidamente los intentos posteriores al máximo y puede alargar la recuperación total. Compare cada espera con los tiempos de espera de solicitudes, los periodos de visibilidad de colas, el restablecimiento de límites de uso y la duración máxima tolerable para sus usuarios. La calculadora muestra esperas anteriores a los reintentos; no incluye la duración de la solicitud original ni el trabajo realizado en cada intento fallido. Sume esos tiempos aparte para estimar el peor caso completo. En sistemas distribuidos, una programación determinista puede hacer que muchos clientes reintenten al mismo tiempo tras una caída compartida. Los clientes de producción suelen añadir una variación aleatoria acotada para repartir la carga y conservan la programación calculada como límite o valor central. Esta capacidad no ejecuta solicitudes, no espera, no contacta servicios ni decide si un error admite reintento. Solo calcula la programación, sin red ni estado almacenado. Puede ejecutarla gratis en el navegador; la automatización mediante API cuesta $0.002 por solicitud.

Revise los ajustes de reintento de un SDK

Convierta los parámetros propuestos en esperas concretas antes de aprobar la configuración de un cliente.

Documente los tiempos de recuperación

Incluya en un manual una programación exacta por intento sin calcular potencias a mano.

Pruebe generadores de configuración

Compare políticas generadas con programaciones deterministas y limitadas mediante comprobaciones automáticas.

¿Qué unidad temporal utiliza la calculadora?

Puede usar cualquier unidad coherente. Si base_delay está en milisegundos, cada demora devuelta y max_delay también estarán en milisegundos.

¿El número de intentos incluye la solicitud inicial?

No. Indica los reintentos posteriores a la solicitud inicial, y la programación contiene exactamente ese número de entradas.

¿Se aplica el máximo antes del primer reintento?

Sí. Todas las demoras están limitadas, incluida la primera, por lo que max_delay puede ser inferior a base_delay.

¿El resultado incluye variación aleatoria?

No. Calcula la programación exponencial determinista. Aplique la variación aparte según las reglas de su cliente.

¿Qué ocurre cuando se alcanza el límite?

La demora permanece en max_delay para ese reintento y para todos los posteriores de la programación solicitada.

Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.

POSThttps://api.kit.forhosting.com/dev2/retry-backoff-schedule

¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.

curl -X POST https://api.kit.forhosting.com/dev2/retry-backoff-schedule \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"base_delay":250,"multiplier":2,"max_delay":8000,"attempts":6}'
{
  "base_delay": 250,
  "multiplier": 2,
  "max_delay": 8000,
  "attempts": 6
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev2.retry_backoff_schedule",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.

Por solicitud$0.002

Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.

max_attempts1000
HTTPCódigoSignificado
401unauthorizedAPI key ausente o inválida.
402insufficient_balanceEl saldo no cubre el precio de la tarea.
404unknown_typeEl tipo de tarea no existe.
429rate_limitedDemasiadas peticiones. Use el webhook en vez de sondear.

Ver la documentación completa del KIT →