Workflow Is Slow v2
Use Step timings and data-flow shape to locate provider latency, clustter routing delay, unnecessary or inefficient enumeration, logging overhead, or a constrained downstream consumer.
Find the slow boundary
Run a representative instance and compare Step start times and durations. Separate:
- Activation and host-acquisition delay.
- Provider or network call duration.
- Mapping and serialization work.
- Deferred collection consumption at a later Step.
- Target throttling or batch commits.
- Parent versus Sub-Workflow time.
A slow data-source Step might not appear slow in the Workflow logs because lazy evaluation produces records only when a later Step requests them. To test a query Step in isolation, use Run to this Step. With no downstream consumer, the Runtime attributes materialization of the produced data to that Step.
Inspect data behavior
Workflows are most efficient when all steps can lazily process data and a given Return is only consumed by one subsequent Step.
Connecting a Stream or Array to more than one downstream Step requires replay, which can add overhead. Some Expression functions, including aggregate functions such as MAX and COUNT, also require the complete data set to be materialized.
Inspect observability cost
Verbose logging, large Property capture, repeated structured previews, and downloaded values can reduce throughput. Log identifiers, counts, timings, and errors instead of entire payloads. Apply redaction without adding duplicate logging Steps.
Review cluster choice and dependencies
Confirm the selected Cluster is close enough to private dependencies and has healthy capacity. Compare provider-side duration or diagnostics when available. A fast network round trip cannot compensate for a slow database query, API throttle, or serialized target operation.
Change one factor, rerun the same bounded input, and compare evidence. Do not rely on an undocumented runtime tuning control.
See Handle Large Data, Lazy Evaluation and Streaming, and Workflow Logging.