It can be normal for “Execute step” (partial executions) to feel slower, especially on larger workflows or after idle periods.
-
Partial executions send extra data/metadata to the backend and can hit size limits or overhead that full runs don’t have. Use a Manual Trigger and run the whole workflow when possible, or temporarily limit data during testing to reduce payload size (Manual, partial, and production executions).
-
Large data in the editor are slower because the UI must stream and render execution data. For heavy runs, execute in the background (active workflow via webhook/schedule) rather than through the editor UI (UI lag on large loops).
-
First runs after idle (“cold”) can be slower; similar reports show initial latency that improves on subsequent runs (first-run slowness examples).
-
If you see timeouts or long node times, reduce items per run (Split in Batches), avoid heavy Code nodes where built-in nodes suffice, and ensure adequate resources; increase execution timeout if needed when self-hosting (heap/memory and batching advice).