fal error_type request_timeout: which Sume field to monitor

fal says a failed request carries an error_type field and an X-Fal-Error-Type header, with values such as request_timeout and runner_disconnected, for retry logic and monitoring. Sume's equivalents are in the error body: code to branch on, category and stage for dashboards, and retryable for the retry decision. The request id also comes as a header, x-sume-request-id; rate-limit responses add retry-after.

fal text from its retries page; Sume text from Errors and spend and Errors and rate limits. Read 2026-10-01.

Where does each service put the category?

On fal, in both the response body and a header, so a proxy can read it without parsing JSON. On Sume, the sources I read show the category inside the JSON error envelope; the documented error headers are the request id and, on rate limits, retry-after.

Which Sume categories mean a timeout?

Two job categories: generation_timeout ("Poll status or retry later") and worker_timeout (same advice). Because the advice starts with polling, check the job status first; the work may have finished after your wait ended. See fal 504 versus generation_timeout.

What should I key alerts on?

Alert on category and stage, which the docs call coarser labels for dashboards and alerts. Route retries on code and retryable. Never match on message, which may change.

What do I attach to a support report?

The request_id and the code. Leave out API keys, signing secrets and raw media URLs. For a general failure walkthrough, see why did my last request fail.