Tempos limite
Como a Autom lida com requisições longas, e como configurar o timeout no seu cliente.
A maioria das requisições responde em poucos segundos, mas alguns endpoints podem demorar mais. Esta página explica nosso limite no servidor e como evitar que seu cliente desista antes de respondermos.
Limite no servidor: 60 segundos
Todas as chamadas de API em tempo real têm um timeout rígido de 60 segundos do nosso lado. As respostas típicas são retornadas em 2 a 3 segundos, ocasionalmente até 30 segundos, e o pior caso antes de abortarmos é 60 segundos.
Se você precisa executar requisições que podem demorar mais de 60 segundos, mude para o modo assíncrono com is_async=true. Veja Parâmetros globais.
Por que sua requisição parece expirar antes
Se você observa timeouts consistentes em exatamente 15s, 30s ou qualquer valor abaixo de 60 segundos, a conexão está quase sempre sendo fechada pela sua própria infraestrutura, não pela nossa API. Seu runtime aborta a chamada HTTP antes que possamos responder.
Sinais comuns:
- Os erros ocorrem na mesma duração exata em cada tentativa (frequentemente 10s, 15s, 25s, 30s).
- Nosso painel mostra a requisição como
200(sucesso) enquanto seu cliente reporta um timeout. - Requisições menores ou em cache funcionam, mas as mais pesadas sempre falham.
Timeouts a verificar conforme sua plataforma
Abaixo os timeouts HTTP / função padrão das plataformas mais comuns. Aumente-os para pelo menos 60 segundos para corresponder ao nosso limite no servidor.
Vercel Serverless e Edge Functions têm timeout padrão de 15s no plano Hobby (até 60s) e 15s no Pro (até 300s, configurável por função).
Defina maxDuration na sua rota ou função:
// app/api/my-route/route.ts (Next.js App Router na Vercel)
export const maxDuration = 60
export async function POST(req: Request) {
// ... chamada da nossa API
}Ou em vercel.json:
{
"functions": {
"app/api/**/*.ts": { "maxDuration": 60 }
}
}Referência: Vercel function duration.
As funções AWS Lambda têm timeout padrão de 3 segundos, configurável até 15 minutos.
# AWS CLI
aws lambda update-function-configuration \
--function-name my-function \
--timeout 60Se você chama o Lambda através do API Gateway, aumente também o timeout de integração (REST APIs: 29s padrão, HTTP APIs: 30s).
As Netlify Functions têm timeout padrão de 10 segundos (síncrono), extensível até 26 segundos. Para requisições mais longas, use Background Functions (até 15 minutos) ou nosso modo assíncrono.
# netlify.toml
[functions]
timeout = 26Os Cloudflare Workers têm um limite de tempo de CPU (10ms / 50ms gratuito, até 30s pago) mas o tempo total é praticamente ilimitado enquanto a conexão permanecer aberta. A maioria dos timeouts vem da chamada fetch upstream.
const res = await fetch("https://api.example.com/...", {
signal: AbortSignal.timeout(60_000),
})O Make.com (anteriormente Integromat) tem timeout HTTP padrão de 40 segundos, configurável por chamada até 300 segundos.
No módulo HTTP → Show advanced settings → defina Timeout para 60 (ou mais).
Se seu cenário para em erros HTTP transitórios, veja também nosso modo soft fail.
A maioria dos clientes HTTP tem um timeout padrão de requisição. Certifique-se de que seja pelo menos 60 segundos:
// fetch Node.js com 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 ...Ainda vendo timeouts?
Se seu cliente está configurado para pelo menos 60 segundos, o modo assíncrono não se encaixa no seu caso, e você ainda vê timeouts, abra um ticket de suporte pelo seu painel com: o endpoint, um request_id de exemplo, o timestamp e o valor de timeout observado. Vamos investigar.
Veja Parâmetros globais para is_async e soft_fail, Códigos de estado para códigos de resposta, e Melhores práticas para orientação de retry.