Autom

Tiempos de espera

Cómo Autom gestiona las solicitudes largas, y cómo configurar el timeout en su cliente.

La mayoría de las solicitudes responden en pocos segundos, pero algunos endpoints pueden tardar más. Esta página explica nuestro límite del lado del servidor y cómo evitar que su cliente cierre la conexión antes de que respondamos.

Límite del servidor: 60 segundos

Todas las llamadas a la API en tiempo real tienen un timeout estricto de 60 segundos en nuestro lado. Las respuestas típicas se devuelven en 2 a 3 segundos, ocasionalmente hasta 30 segundos, y el peor caso antes de que abortemos es 60 segundos.

Si necesita ejecutar solicitudes que pueden tardar más de 60 segundos, use el modo asíncrono con is_async=true. Vea Parámetros globales.

Por qué su solicitud parece expirar antes

Si observa timeouts constantes a exactamente 15s, 30s o cualquier valor inferior a 60 segundos, la conexión casi siempre la está cerrando su propia infraestructura, no nuestra API. Su runtime aborta la llamada HTTP antes de que tengamos tiempo de responder.

Señales comunes:

  • Los errores ocurren con la misma duración exacta en cada reintento (a menudo 10s, 15s, 25s, 30s).
  • Nuestro panel muestra la solicitud como 200 (éxito) mientras su cliente reporta un timeout.
  • Las solicitudes pequeñas o cacheadas tienen éxito, pero las más pesadas siempre fallan.

Timeouts a verificar según su plataforma

A continuación los timeouts HTTP / función por defecto de las plataformas más comunes. Auméntelos a al menos 60 segundos para coincidir con nuestro límite del servidor.

Vercel Serverless y Edge Functions tienen un timeout por defecto de 15s en el plan Hobby (hasta 60s), y 15s en Pro (hasta 300s, configurable por función).

Defina maxDuration en su ruta o función:

// app/api/my-route/route.ts (Next.js App Router en Vercel)
export const maxDuration = 60

export async function POST(req: Request) {
  // ... llamada a nuestra API
}

O en vercel.json:

{
  "functions": {
    "app/api/**/*.ts": { "maxDuration": 60 }
  }
}

Referencia: Vercel function duration.

Las funciones de AWS Lambda tienen un timeout por defecto de 3 segundos, configurable hasta 15 minutos.

# AWS CLI
aws lambda update-function-configuration \
  --function-name my-function \
  --timeout 60

Si llama a Lambda a través de API Gateway, también aumente el timeout de integración (REST APIs: 29s por defecto, HTTP APIs: 30s).

Las Netlify Functions tienen un timeout por defecto de 10 segundos (síncrono), ampliable a 26 segundos. Para solicitudes más largas, use Background Functions (hasta 15 minutos) o nuestro modo asíncrono.

# netlify.toml
[functions]
  timeout = 26

Los Cloudflare Workers tienen un límite de tiempo CPU (10ms / 50ms gratis, hasta 30s pago) pero el tiempo total es prácticamente ilimitado mientras la conexión permanezca abierta. La mayoría de los timeouts vienen de la llamada fetch upstream.

const res = await fetch("https://api.example.com/...", {
  signal: AbortSignal.timeout(60_000),
})

Make.com (anteriormente Integromat) tiene un timeout HTTP por defecto de 40 segundos, configurable por llamada hasta 300 segundos.

En el módulo HTTP → Show advanced settings → defina Timeout en 60 (o más).

Si su escenario se detiene en errores HTTP transitorios, vea también nuestro modo soft fail.

La mayoría de los clientes HTTP tienen un timeout por defecto. Asegúrese de que sea al menos 60 segundos:

// fetch Node.js con AbortController
const controller = new AbortController()
const timer = setTimeout(() => controller.abort(), 60_000)
try {
  const res = await fetch(url, { signal: controller.signal })
} finally {
  clearTimeout(timer)
}
# requests Python
import requests
requests.get(url, timeout=60)
# curl
curl --max-time 60 ...

¿Sigue viendo timeouts?

Si su cliente está configurado para al menos 60 segundos, el modo asíncrono no se ajusta a su caso, y aún ve timeouts, abra un ticket de soporte desde su panel con: el endpoint, un request_id de ejemplo, el timestamp y el valor de timeout observado. Lo investigaremos.

Vea Parámetros globales para is_async y soft_fail, Códigos de estado para los códigos de respuesta, y Buenas prácticas para estrategias de reintento.

En esta página