> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xsiam-developer-guide/cortex-xsiam-development-guide/integrations-and-scripts/advanced-topics/long-running-containers.md).

# Long Running Containers

You can use long running containers to run specific processes in an integration indefinitely. To use long running containers, the integration must be written in Python.

**Enable the longRunning property**

To make an integration long running, to enable the `longRunning` property:

![](/files/Ifsd4tz8o2gRhF5tg6SB)

You can then see the **Long running integration** parameter in the instance configuration options.

When you select the checkbox, the server launches a long running container each time an instance is enabled. When the checkbox is cleared or the instance is disabled, the container dies. Long running containers contain **LongRunning** in the container name.

![](/files/ljjOF37HQAKiKDordXBG)

**Integrations that are long running by default**

Some integrations are long running by default. These integrations do not include the **Long running integration** checkbox. Example of such integrations include:

* Generic Export Indicators Service (EDL)
* Generic Webhook
* AWS SNS Listener
* TAXII2 Server
* TAXIIServer

For these integrations, the long-running behavior is inherent and cannot be modified.

These integrations can operate in **Single engine** mode or **No engine** mode. When using single engine mode, select your engine in the integration configuration and specify the port number for the **Listen Port**. When using no engine mode, select **No engine** in the integration configuration. The server automatically assigns a port for the instance.

**Implementation**

When the container runs, it calls a dedicated command in the integration, similar to `fetch-incidents`. The command is called `long-running-execution`. To use a long running container, you need to implement `long-running-execution` in your integration code. For the code to run code forever, it must never stop executing. For example, you can use a never ending loop (`while True`).

**Interaction with the server**

Since the long running container does not run within a scope of an incident, it has no standard place to output results to. Instead there are dedicated functions to interact with the server:

* `addEntry` - Adds an entry to a specified incident War Room. For more details, see the [API reference](https://xsoar.pan.dev/docs/reference/api/demisto-class#addentry).
* `createIncidents` - Creates incidents according to a provided JSON. For more details, see the [API reference](https://xsoar.pan.dev/docs/reference/api/demisto-class#createincidents).
* `findUser` - Finds a Cortex XSIAM user by a name or email. Useful for creating incidents. For more details, see the [API reference](https://xsoar.pan.dev/docs/reference/api/demisto-class#finduser).
* `handleEntitlementForUser` - Adds an entry with entitlement to a provided investigation. For more details, see the [API reference](https://xsoar.pan.dev/docs/reference/api/demisto-class#handleentitlementforuser).
* `updateModuleHealth` - Updates the instance status. This is a way to reflect the container state to the user. For more details, see the [API reference](https://xsoar.pan.dev/docs/reference/api/demisto-class#updatemodulehealth).

  ![](/files/PVFN7xbPqzis7hrqLLnp)
* `mirrorInvestigation` - For chat based integrations, mirrors a provided Cortex XSIAM investigation to the corresponding chat module.
* `directMessage` - For chat based integrations, handles free text sent from a user to the chat module and processes it in the server.

**Manage container states**

One of the most important and useful aspects of the long running process is the integration context: `demisto.setIntegrationContext(context)` `demisto.getIntegrationContext()`  You can use the integration context to store information and manage the state of the container per integration instance. This context is stored in a format of a dict of `{'key': 'value'}`, where the value must be a string. To store complex objects as values, parse them to JSON.

Use logging to notify and report different states inside the long running process: `demisto.info(str)` and `demisto.error(str)`. These will show up in the server log.

**Troubleshooting**

Use `updateModuleHealth`, `info` and `error` to report errors and debug. It's also important to segregate the logic into functions so you can unit test them.

**Best practices**

* Do not use `sys.exit()`, use `return_error` instead.
* Always catch exceptions and log them.
* Run in a never ending loop.

To run multiple processes in parallel, you can use async code. For example, view the **Slack v2** and **Microsoft Teams** integrations.

**Invoke HTTP integrations via Cortex XSIAMserver's route handling**

For details, see [Invoking long running HTTP integrations via server's HTTPS endpoint](https://xsoar.pan.dev/docs/reference/articles/long-running-invoke).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/cortex-xsiam-developer-guide/cortex-xsiam-development-guide/integrations-and-scripts/advanced-topics/long-running-containers.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.