Timeout
The deadline you put on a call you don't control: wait this long, then give up and move on instead of hanging forever.
See it
What it is
A timeout is the deadline you attach to a call you do not control. Without one, a slow dependency holds your connection, worker, or serverless invocation hostage until some other limit kills it, and one sluggish vendor takes your whole app down with it. There are usually three dials: connect (getting a socket at all), read (waiting for bytes once connected), and a total deadline covering the whole operation including retries.
Set one on every outbound HTTP call, every database query in a request path, and every message a queue consumer picks up. Note the wording on that last one: the consumer process is meant to sit there alive for weeks, so the deadline belongs to the handling of one message and the calls it makes, not to the loop that pulls them. In JavaScript that is AbortSignal.timeout(ms) passed to fetch; most SDKs take a timeout option. Keep your number comfortably under the platform ceiling (the gateway, the function duration limit) so you return your own friendly error instead of an opaque 504.
The gotcha that bites everyone: a timeout cancels your waiting, not their work. The charge may have gone through, the email may have sent, the row may exist. That is why timeouts and idempotency keys travel together, and why a blind retry after a timeout on a non-idempotent write is how you charge someone twice.
Ask AI for it
Add explicit timeouts to every outbound call in this codebase. Use AbortSignal.timeout() with fetch (or the SDK's timeout option), pick a value well under the platform's own function or gateway limit, and distinguish connect, read, and total-deadline budgets when the client supports it. On expiry, surface a specific timeout error instead of a generic 500, log the target and elapsed time, and only retry the call automatically if the operation is idempotent or carries an idempotency key.