> For the complete documentation index, see [llms.txt](https://docs.helmut.de/helmut4-releases/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.helmut.de/helmut4-releases/helmut4-components/streamdesigner/nodes/actions/misc-21/split-stream-action.md).

# Split Stream Action

The **Split Stream Action** node splits a stream into two execution paths:

* a **synchronous path** (must finish quickly)
* an **asynchronous path** (can run longer)

This node is required whenever a stream may exceed the **60-second execution limit**. If the synchronous part does not complete within 60 seconds, the stream will fail. The asynchronous path can run longer than 60 seconds, but it still executes sequentially within itself.

<figure><img src="/files/E7Zup5bbIu8fWZd2G0HY" alt=""><figcaption><p>Typical use of a split stream action</p></figcaption></figure>

#### Why This Node Exists

Long-running operations such as copying, rendering, or multi-step processing (especially in **IO, CO, or HK** contexts) cannot reliably finish within 60 seconds. By splitting the stream, you keep the trigger response fast while continuing heavy work safely in the background.

#### Recommended Usage

**1) Keep the sync path short**\
All nodes on the synchronous path must finish within 60 seconds.

**2) Add a short Sleep on the sync path**\
If the synchronous path has no meaningful actions after the split, connect it to a **Sleep** node (e.g., **\~123 ms**).\
This forces the dashboard to create a debug log immediately. Otherwise, the log may only appear after the asynchronous path finishes — which is problematic if the async part fails early.

**3) Put long processes into the async path**\
Copying, transcoding, rendering, and other multi-node procedures should run on the asynchronous path.

{% hint style="warning" %}

#### Important Restrictions

* **Do not use this node in FX streams.**\
  It may cause issues with certain FX triggers (e.g., create/open project).
* **Do not use multiple Split Stream nodes in one stream.**\
  Only one instance should be used per stream.
* **If you still hit timeouts:**\
  Split the logic into multiple separate streams and run them sequentially via the trigger event instead of trying to chain everything in one stream.

{% endhint %}

#### Behavior

* Creates a synchronous and an asynchronous branch
* Sync branch must complete within 60 seconds
* Async branch can exceed 60 seconds and continues processing in the background
* The async branch is still executed sequentially (synchronously within itself)

#### Typical Use Cases

* long file copies (IO/CO/HK)
* render and transcode workflows
* multi-step ingest / delivery processing
* operations where progress/log visibility matters in the dashboard

#### Practical Summary

Use this node when you need to start heavy processing without risking the 60-second stream timeout.\
Keep the sync side minimal (and ideally end it with a short Sleep), and run the real work on the async side.