STITCH_TIMEOUT

What you'll see

A call aborts and throws a StitchError once a configured timeout elapses. timeout.total bounds the whole call across every retry and its backoff; timeout.each bounds a single attempt. The runtime enforces these with a real AbortSignal, so the in-flight request is actually aborted rather than left running while the call gives up — the underlying request receives the abort.

Why it happens

Two distinct triggers land here:

• The dependency is slow or unreachable. The request genuinely takes longer than the budget you allowed — a degraded upstream, a cold start, or a host that never answers and ties up the attempt until the signal fires.
• The budget is too tight. each is shorter than the dependency's normal latency, so healthy responses get cut off; or total doesn't leave room for every attempt plus the backoff between them, so the whole call aborts mid- way through a retry sequence that would otherwise have succeeded.

How to fix

Raise total and each to a realistic budget for the dependency's actual latency. When you also configure retry, make total large enough to cover the full sequence — as a rule of thumb, total ≥ attempts × (each + backoff) — so the call isn't aborted partway through a retry that would have landed.

import { stitch } from 'stitchapi';

const report = stitch({
    baseUrl: 'https://api.example.com',
    path: '/reports/slow',
    retry: { attempts: 3, backoff: { base: 200 } },
    timeout: {
        // Each attempt gets 5s; the whole call (3 attempts + backoff) gets 20s.
        each: '5s',
        total: '20s',
    },
});

Check the dependency's measured latency before widening the budget — if it is consistently slow or flapping, a longer timeout only delays the failure. For a dependency that is genuinely failing, pair the timeout with retry for transient blips and a circuit breaker to fast-fail once it stops responding, instead of waiting out the timeout on every call.

Related