Timeouts
Wie Autom lange Anfragen verarbeitet und wie Sie Ihren Client konfigurieren.
Die meisten Anfragen antworten in wenigen Sekunden, einige Endpunkte können jedoch länger dauern. Diese Seite erklärt unser serverseitiges Limit und wie Sie sicherstellen, dass Ihr Client nicht aufgibt, bevor wir antworten.
Serverseitiges Limit: 60 Sekunden
Alle Echtzeit-API-Aufrufe haben auf unserer Seite einen festen Timeout von 60 Sekunden. Typische Antworten kommen in 2 bis 3 Sekunden zurück, gelegentlich bis zu 30 Sekunden, und das absolute Maximum vor Abbruch sind 60 Sekunden.
Wenn Sie Anfragen ausführen müssen, die länger als 60 Sekunden dauern können, wechseln Sie in den asynchronen Modus mit is_async=true. Siehe Globale Parameter.
Warum Ihre Anfrage scheinbar früher abbricht
Wenn Sie konstante Timeouts bei genau 15s, 30s oder einem anderen Wert unter 60 Sekunden beobachten, wird die Verbindung fast immer von Ihrer eigenen Infrastruktur geschlossen, nicht von unserer API. Ihre Runtime bricht den HTTP-Aufruf ab, bevor wir antworten können.
Häufige Anzeichen:
- Fehler treten bei jedem Versuch nach genau derselben Dauer auf (oft 10s, 15s, 25s, 30s).
- Unser Dashboard zeigt die Anfrage als
200(Erfolg), während Ihr Client einen Timeout meldet. - Kleinere oder gecachte Anfragen funktionieren, aber schwerere schlagen immer fehl.
Zu prüfende Plattform-Timeouts
Nachfolgend die Standard-HTTP-/Funktions-Timeouts der gängigsten Plattformen. Erhöhen Sie sie auf mindestens 60 Sekunden, um unserem serverseitigen Limit zu entsprechen.
Vercel Serverless und Edge Functions haben einen Standard-Timeout von 15s im Hobby-Plan (bis zu 60s) und 15s im Pro-Plan (bis zu 300s, pro Funktion konfigurierbar).
Setzen Sie maxDuration in Ihrer Route oder Funktion:
// app/api/my-route/route.ts (Next.js App Router auf Vercel)
export const maxDuration = 60
export async function POST(req: Request) {
// ... Aufruf unserer API
}Oder in vercel.json:
{
"functions": {
"app/api/**/*.ts": { "maxDuration": 60 }
}
}Referenz: Vercel function duration.
AWS-Lambda-Funktionen haben einen Standard-Timeout von 3 Sekunden, konfigurierbar bis zu 15 Minuten.
# AWS CLI
aws lambda update-function-configuration \
--function-name my-function \
--timeout 60Wenn Sie Lambda über API Gateway aufrufen, erhöhen Sie auch den Integrations-Timeout (REST APIs: 29s Standard, HTTP APIs: 30s).
Netlify Functions haben einen Standard-Timeout von 10 Sekunden (synchron), erweiterbar auf 26 Sekunden. Für längere Anfragen verwenden Sie Background Functions (bis zu 15 Minuten) oder unseren asynchronen Modus.
# netlify.toml
[functions]
timeout = 26Cloudflare Workers haben ein CPU-Zeit-Limit (10ms / 50ms kostenlos, bis zu 30s im Bezahlplan), aber die Wandzeit ist im Wesentlichen unbegrenzt, solange die Verbindung offen bleibt. Die meisten Timeouts kommen vom Upstream-fetch-Aufruf.
const res = await fetch("https://api.example.com/...", {
signal: AbortSignal.timeout(60_000),
})Make.com (früher Integromat) hat einen Standard-HTTP-Timeout von 40 Sekunden, pro Aufruf bis zu 300 Sekunden konfigurierbar.
Im HTTP-Modul → Show advanced settings → Timeout auf 60 (oder höher) setzen.
Wenn Ihr Szenario bei vorübergehenden HTTP-Fehlern stoppt, sehen Sie sich auch unseren Soft-Fail-Modus an.
Die meisten HTTP-Clients haben einen Standard-Request-Timeout. Stellen Sie sicher, dass er mindestens 60 Sekunden beträgt:
// Node.js fetch mit AbortController
const controller = new AbortController()
const timer = setTimeout(() => controller.abort(), 60_000)
try {
const res = await fetch(url, { signal: controller.signal })
} finally {
clearTimeout(timer)
}# Python requests
import requests
requests.get(url, timeout=60)# curl
curl --max-time 60 ...Immer noch Timeouts?
Wenn Ihr Client für mindestens 60 Sekunden konfiguriert ist, der asynchrone Modus für Ihren Anwendungsfall nicht passt und Sie weiterhin Timeouts sehen, öffnen Sie bitte ein Support-Ticket über Ihr Dashboard mit: dem Endpoint, einer Beispiel-request_id, dem Zeitstempel und dem beobachteten Timeout-Wert. Wir prüfen das.
Siehe Globale Parameter für is_async und soft_fail, Statuscodes für Antwortcodes und Best Practices für Retry-Hinweise.