The MC Queue node is used to manage long running tasks. It takes the payload of the incoming message, it stores it a SQLite queue and redirect the stored payloads to the output pin one by one, at regular interval.
The typical use is broadcasting the same message to a large set of users with a regular pace, accepted by the chat platform, the broadcast is split in single tasks, it can be stopped or resumed, it’s stored in a database and survives across Node-RED’s restarts and can be inspected with the Mission Controls queues panels.

Simple send to recipients flow
| Name | Description |
|---|---|
| name | The name of the queue, if left blank is default |
| initialState | The initial state of the queue: running or pause. If running it will start consuming elements from the queue as soon as the flow is deployed |
| type | The type of the queue: sequential or stops after each element. If sequential it will continue to consume elements from the queue at a pace defined by delay, otherwise the queue is paused after each consumed element. |
| delay | The delay in ms between elements consumed by the queue. It also accepts variables from the flow and global context, for example {{flow.myDelay}} or {{global.someDelay}} |
It’s possible to issue commands to the queue with a simple inbound message
{
mycommand: true
}
Available commands
| Command | Description |
|---|---|
| start | Start a paused queue |
| next | Consume next element of the queue |
| pause | Pause a running queue |
The stops after each element queue type is useful in scenarios where each element of the queue needs to be extracted when the previous task is completed, for example a FTP server which doesn’t allow concurrent uploads

Retroaction to execute one element at a time
Here a simple retro-action of the function node which sends to the output a msg { next: true } which triggers the extraction of the next element of the queue only when the previous element is uploaded completely.
The payload added to the queue can contain a taskId, which identifies the task, if a task with the same taskId already exists in the queue, then the new payload will be merged with the existing one. If no taskId is provided, then a random one is assigned.