Request timeout / execution limit
The clock that decides when a slow request stops waiting or when a hosted function is forcibly stopped.
See it
What it is
A request timeout is how long a client, proxy, or platform will wait for a response. An execution limit is how long the platform lets the code keep running. Those clocks can differ: a proxy may return a 504 while work continues downstream, or a serverless platform may terminate the function at its hard limit.
The numbers are worth memorizing because they are the ones you will hit. Heroku's router kills a request at 30 seconds and logs it as H12. AWS Lambda stops a function at 15 minutes. Cloudflare Workers bills CPU time, not wall-clock time, so a Worker can wait on a slow API far longer than its CPU budget suggests. Read your platform's limit before designing around a number you guessed.
Reach for a short, explicit timeout around network calls so one slow dependency does not occupy capacity forever. Move genuinely long work such as video encoding or large exports to a queue and return a job ID instead of holding an HTTP request open.
Retries after a timeout can repeat work whose result arrived too late to be seen. Give writes an idempotency key, cancel downstream work where possible, and keep each inner timeout shorter than the outer platform limit.
Ask AI for it
For this Next.js route deployed on Vercel, export const maxDuration = 30, pass AbortSignal.timeout(25_000) to every outbound fetch, and translate an abort into a 504 response with a request ID. Move work that cannot finish inside 25 seconds to a Vercel Queue or an Amazon SQS queue, return 202 with the job ID, and make the queued handler idempotent so a retry cannot apply the same write twice.