Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

timeout_ms

timeout_ms bounds workflow execution for one message. A synchronous request that exceeds it answers 504 Gateway Timeout.

Synopsis

{ "timeout_ms": 5000 }

Fields

FieldTypeRequiredDefaultDescription
timeout_msintegernoper ingress, belowMaximum workflow execution time in milliseconds.

The value governs every ingress. Where the channel declares none, each ingress falls back to its own server-level default. On two ingresses that server value is a ceiling the channel value is clamped to, never a default:

IngressChannel declares noneChannel declares more than the transport allows
synchronous HTTPruns to completionhonored — nothing else waits on it
/asynctrace_queue.processing_timeout_msclamped to trace_queue.processing_timeout_ms
Kafkakafka.processing_timeout_msclamped to kafka.processing_timeout_ms
channel_callengine.default_channel_call_timeout_mshonored — the calling task’s own timeout_ms outranks it anyway
Why the two clamps

On those paths the deadline protects something shared. A Kafka dispatch blocks the consumer’s poll loop. A channel asking for ten minutes would push the consumer past librdkafka’s max.poll.interval.ms and get it evicted from its group mid-record. An /async dispatch occupies one of a fixed number of queue workers, so an over-long deadline starves every other channel’s queued work. A channel can shorten its deadline everywhere; it can lengthen it only where nothing else depends on it. Raise the transport setting if a channel genuinely needs longer there.

A channel_call task may set its own timeout_ms, which outranks the target channel’s. See Task Functions. The server-level settings live in the Configuration Reference.

Last verified 14 September 2026