---
title: "Timeouts in Unqork"
slug: "timeouts-in-unqork"
description: "Learn how to prevent timeouts in Unqork workflows, data processing, and MongoDB to enhance application performance and avoid unexpected issues."
updated: 2026-05-29T15:25:47Z
published: 2026-05-29T15:25:47Z
canonical: "docs.unqork.io/timeouts-in-unqork"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.unqork.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Timeouts in Unqork

**Timeouts** occur when a process reaches a preset time limit. When it reaches that time limit, unexpected behavior may occur. Timeouts can lead to significant problems in your application and become a greater issue as the application’s scale increases.

When working in Unqork, you can prevent timeouts in a few ways. In a workflow, large data sets can be processed in batches. Or, a [Timer](/v1/docs/timer-node) node can be used to make the application run longer than the set timeout. Additionally, [Data Workflows](/v1/docs/data-workflow-component) using indexed MongoDB queries, with properly maintained data, can also prevent timeouts.

## Avoiding Timeouts

Click on the tabs below to learn more about avoiding timeouts in specific elements of Unqork:

WorkflowData WorkflowsPlug-In ComponentMongoDB Queries

### Workflow

A workflow running multiple processes stops if it exceeds the five-minute limit. There are two methods to ensure an automated workflow does not timeout. The first is to run potentially large data sets in smaller batches, instead of a large one. It's important to note that the overall automated workflow has a time limit of five minutes, while each module included in the workflow has an individual time limit of two minutes. So, you must manage the execution time of each module, along with the overall workflow.

### Data Workflows

There are a few ways to ensure your [Data Workflows](/v1/docs/data-workflow-component) do not reach the two-minute timeout. The first is to separate large Data Workflows into smaller ones. That way, each part runs more quickly and has less of a chance to timeout. The next best practice is to be thoughtful about how you order the operations. If possible, connect [Filter](/v1/docs/filter-operator) operators earlier in the Data Workflow so that later operators perform actions on smaller data sets. Like workflows, you can perform batch processes using a batch loop. Batch loops let you work on a smaller, more manageable data set.

To learn more about available loop snippets in Unqork, view the following links:

- [Batch Loop Snippet](/v1/docs/batch-loop-snippet)
- [Do While Loop Snippet](/v1/docs/simple-loops-do-while-loop-snippet)
- [For Loop Snippet](/v1/docs/simple-loops-for-loop-snippet)
- [While Loop Snippet](/v1/docs/simple-loops-while-loop-snippet)

### MongoDB Queries

While we recommend using queries over Data Workflows to improve performance because timeouts can still occur as submissions increase. It’s also important to clean your database. As submissions accumulate, performance decreases if unnecessary submissions are not removed. The most efficient way to remove these submissions is to build an automated workflow that deletes them.

### Plug-In Component

The **Set Timeout** setting in the [Plug-In](/v1/docs/plug-in-component) component controls the maximum time the Plug-In component should wait for a response from the called module or service. You can use this setting to define a timeout up to 300,000 ms (5 minutes). If no setting is specified, the default timeout is 120,000 ms (2 minutes).

The Plug-In component timeout is a client timeout only. Meaning, when the timeout is reached, the component stops waiting for a response, and an `Error: timeout of {duration}ms exceeded` is returned.

Client-side timeouts do not terminate the execution of a called Unqork server-side module. A triggered server-side module might run for more than two minutes once it’s invoked, even though the Plug-In component stopped waiting for a response. Your component might also call an external service, which might have its own limits for execution duration and timeouts.

In addition to batch processing, you can use a [Timer](/v1/docs/timer-node) node to ensure the process does not timeout. The workflow resets the server-side process every time it progresses to the Timer node. If you have a process that takes longer than five minutes, add a Timer node on a loop to keep the workflow running. Bulk Processing Using a Workflow

Now, let’s look at an example of using bulk processing for workflows. In this example, you’ll learn how to use an automated workflow to complete bulk processes, like deleting or updating all submissions. We’ll review the necessary steps and focus on batching logic. Depending on the number of submissions you’ll process, there’s the potential that your workflow might timeout. However, you can configure a Timer node to prevent timeout issues.

For this example, we’ll review the configuration of the Batch Process found here: [https://training.unqork.io/app/designer#/display/module-builder?moduleId=64f22a1e926ee36c5c18f32f](https://training.unqork.io/app/designer#/display/module-builder?moduleId=64f22a1e926ee36c5c18f32f).

Open the module and make a copy of its definition to explore its configuration.

### On Load Field Group Component

First, let's review the on-load logic of the module.

![On Load section displaying schemaModuleId and sseModuleId with initOnLoad highlighted.](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/Timeouts_OnLoad.jpg?sv=2026-02-06&spr=https&st=2026-11-08T18%3A05%3A08Z&se=2026-11-08T19%3A05%3A08Z&sr=c&sp=r&sig=VYwh8n8VkdlCYoHUG1KTBbujuI6UpO2%2BN4wUThv%2F1Ic%3D)

The first [Field Group](/v1/docs/field-group-component) component contains the on-load logic. This component includes one [Initializer](/v1/docs/initializer-component) and two [Hidden](/v1/docs/hidden-component) components. These Hidden components determine the functionality of the batch processing. One component contains a schema ID as the source for the processed submissions. The other component contains a server-side execution ID that processes the submissions. The Initializer component triggers a [Plug-In](/v1/docs/plug-in-component) component to retrieve the submissions, while using the **Edit Submission** Trigger Type because it's part of a workflow.

#### Get and Update Submissions Field Group Component

Now, let’s review the logic necessary to retrieve the correct submissions for each batch.

![Overview of submission management functions including current offset and submission counts.](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/Timeouts_GetUpdate.jpg?sv=2026-02-06&spr=https&st=2026-11-08T18%3A05%3A08Z&se=2026-11-08T19%3A05%3A08Z&sr=c&sp=r&sig=VYwh8n8VkdlCYoHUG1KTBbujuI6UpO2%2BN4wUThv%2F1Ic%3D)

The `currentOffset` **Hidden** component has a **Default Value** of `0`. With each batch, it updates and uses the new value in the **Get Submissions** call. Doing so ensures it retrieves a new batch of submissions each time it runs. The Plug-In component making the call uses the following **Data Source URL**:

`/fbu/uapi/modules/{{data.schemaModuleId}}/submissions?sort=created&offset={{data.currentOffset}}&dataFields=noFields&limit=20`

The call uses the schema ID and a current offset that returns a batch of 20 submissions. Then, the Plug-In component triggers the `dwfSetSubmissionsAndOffset` **Data Workflow** using a post-trigger.

> You can use the `dataFields=noFields` parameter to return submission IDs only.

Next, let’s review the various tasks the Field Group component's Data Workflow performs.

![Data workflow diagram showing inputs, outputs, and processing steps for submissions.](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/Timeouts_SetDWF.jpg?sv=2026-02-06&spr=https&st=2026-11-08T18%3A05%3A08Z&se=2026-11-08T19%3A05%3A08Z&sr=c&sp=r&sig=VYwh8n8VkdlCYoHUG1KTBbujuI6UpO2%2BN4wUThv%2F1Ic%3D)

First, the Data Workflow inputs the submissions returned by the `plugGetSubs` **Plug-In** component, and sets the **Default Value** of the `countOfSubmissions` **Hidden** component. Next, the Data Workflow determines if the number of submissions is greater than zero. If the value is greater than zero, the Data Workflow runs another batch. If it equals zero, it stops and creates a value of `'no'`, outputting it to the `runAgain` **Hidden** component. Retrieved submissions include the submission ID and an index that is stored in the `submissions` **Hidden** component. The **offset** of `20` ensures the Plug-In component retrieves the next batch of submissions when it repeats the loop.

After the Data Workflow populates the `countOfSubmissions` and `submissions` **Hidden** components, it triggers another Data Workflow component. Open the configuration drawer of the `dwfSplitSubs` **Data Workflow**, and you’ll see that it performs various complex tasks. However, the process is quite simple.

This Data Workflow inputs the submissions with their submission ID and index. It filters for a submission using `order=0` to return a single submission. It retrieves the submission ID and stores it in a Hidden component. Then, the Data Workflow triggers a Plug-In component. This process repeats 20 times, or as many times as there are submissions. Each submission ID is stored in its associated Hidden component and then triggers its Plug-In component.

#### SSE Update Plugins Field Group Component

Like the previous Data Workflow, the logic in this [Field Group](/v1/docs/field-group-component) component repeats 20 times. It consists of 20 [Panel](/v1/docs/panel-component) components, each containing an [Initializer](/v1/docs/initializer-component), [Plug-In](/v1/docs/plug-in-component), and two [Hidden](/v1/docs/hidden-component) components. Each Panel component retrieves and stores a single submission.

The image below displays a portion of the configuration in the `SSE Update Plugins` **Field Group** component:

![Overview of SSE Update Plugins with various update statuses and flags for each module.](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/Timeouts_SSEUpdate.jpg?sv=2026-02-06&spr=https&st=2026-11-08T18%3A05%3A08Z&se=2026-11-08T19%3A05%3A08Z&sr=c&sp=r&sig=VYwh8n8VkdlCYoHUG1KTBbujuI6UpO2%2BN4wUThv%2F1Ic%3D)

To explain the configuration in these Panel components, let's begin with the `subToUpdateA` **Hidden** component. The `dwfSplitSubs` **Data Workflow** sets the Hidden component's **Default Value** to the first submission ID. The Data Workflow also triggers the `plugSubToUpdateA` **Plug-In** component, which makes an **Execute Module API** call on the `sseModuleId` **Hidden** component determines the process you want to complete. This Plug-In component also uses a post-trigger to trigger the `initDoneUpdateA` **Initializer** component. This Initializer component sets `flagDoneA` **Hidden** component's **Default Value** to `1`, and triggers the `calcAllDone` **Calculator** component. This logic repeats, increasing the value until all submissions are retrieved.

Because the Data Workflow triggers each Plug-In component separately, they run asynchronously. This process improves the application's performance and efficiency. If, for some reason, the `plugSubToUpdateA` **Plug-In** component takes a long time to finish, the `plugSubToUpdateB` **Plug-In** component does not have to wait before it runs.

> While you could create a larger batch with 100 or 1000 submissions, you risk overloading the server when you make that many calls simultaneously. Batches of 20 are a reliable and efficient size.

#### Response & Retrigger Field Group Component

The final [Field Group](/v1/docs/field-group-component) component contains a [Calculator](/v1/docs/calculator-component) and [Decisions](/v1/docs/how-to-guide-decisions-component) component that controls when the loop should repeat or end.

![Workflow diagram illustrating various flags and conditions for process completion.](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/Timeouts_ResponseRetrigger.jpg?sv=2026-02-06&spr=https&st=2026-11-08T18%3A05%3A08Z&se=2026-11-08T19%3A05%3A08Z&sr=c&sp=r&sig=VYwh8n8VkdlCYoHUG1KTBbujuI6UpO2%2BN4wUThv%2F1Ic%3D)

After the Plug-In component runs, the `calcAllDone` **Calculator** component determines when the batch is finished. It checks each batch’s `flagDone` **Hidden** component and determines if they add up to `20`. If they do, it sets the `allDoneFlag` **Hidden** component’s **Default Value** to `1`. If the value is not `20`, it sets the **Default Value** to `0`. When all the Plug-In components have finished, the `ruleAllDone` **Hidden** component triggers the `dwfRunAgain` **Data Workflow** component.

If the `countOfSubmissions` **Hidden** component’s value is `20`, the Data Workflow sets the `runAgain` **Hidden** component’s value to `‘yes’`. If the value is less than `20`, no more submissions exist, and the `runAgain` **Hidden** component’s **Default Value** is set to `‘no’`. Then, the workflow checks the `runAgain` **Hidden** component’s **Default Value**. If the value is `'yes'`, the batch process runs again. If the value is `'no’`, the workflow ends.

In Unqork an application is a program used to perform specific tasks. An application can be one of two types: workflow or module.

The location of an element in an array.

A query lets you retrieve, access, manipulate, and delete data in a database.

Also known as Record Data. Submission data consists of information saved by Unqork components. View submission data by using the angular command, or in Record Collections.

A UI (User Interface) Drawer is a layout panel that slides out from the side of the screen to display content. In UDesigner, components display their configuration panels in a drawer.