---
title: "Manage Concurrency"
description: "Control how many flows can run at the same time per project"
icon: 'gauge'
---

## Overview

Concurrency limits control how many flow runs can execute simultaneously within a project. When a project reaches its limit, new runs are queued and retried automatically with exponential backoff until a slot becomes available.

This is useful to:

- Prevent a single project from consuming all available workers.
- Protect downstream APIs from being overwhelmed by too many parallel requests.
- Ensure fair resource distribution across projects on your platform.

## Setting a Per-Project Limit

1. Navigate to **Project Settings > General**.
2. Find the **Max Concurrent Jobs** field.
3. Enter the desired limit, or leave it empty to use the platform default.
4. Click **Save**.

![Project Settings — Max Concurrent Jobs](/resources/screenshots/manage-concurrency.png)

When the field is empty, the project uses the default concurrency limit from your platform plan.

## What Happens When the Limit Is Reached

When a project hits its concurrency limit:

1. New flow runs are **not dropped** — they are queued.
2. The system retries queued runs with **exponential backoff**.
3. Once an active run finishes and a slot opens, the next queued run starts.

This means flows will always eventually execute, but they may experience delays when the project is at capacity.

## Programmatic Management via Embedding

If you are embedding Activepieces, you can manage concurrency limits programmatically through the JWT token used to provision users. This allows you to group multiple projects into a shared **concurrency pool** so they share the same limit.

See [Provision Users](/embedding/provision-users) for the `concurrencyPoolKey` and `concurrencyPoolLimit` JWT claims.
