Hi @ALEX LIMA ,

Instead of using Sleep (which can sometimes lead to timeouts), you could consider using a retry queue with a Timer.

When an API call fails, you can:

• Save the request in a Retry table, including the number of attempts and the next retry time.

• Avoid waiting or sleeping in the current process.

Then have a Timer that runs regularly (for example every minute, or any custom interval) and checks for items that need to be retried. The Timer can attempt the API call again, and if it still fails, simply increase the attempt count and schedule the next retry with a delay.

This approach usually works better because it doesn’t block server threads and helps avoid timeouts.

Regards,

Manish Jawla

Hi @ALEX LIMA , 
A retry mechanism using asynchronous processing, such as a Timer or background process, combined with a retry counter and a calculated delay stored in the database. When a service call fails due to timeout, you can store the request, increment the retry count, and schedule the next attempt using an exponential backoff formula with jitter. The Timer can periodically check pending retries and execute them without blocking threads. 

Using Sleep in a web request thread is generally a recipe for disaster in OutSystems. It ties up a worker thread from the IIS pool, which can quickly lead to thread exhaustion, slowing down your entire environment even if the traffic is low.

To implement a retry pattern with jitter without "hanging" your application, you need to move from a synchronous approach to an asynchronous one.

Another way to handle retries with jitter in OutSystems is using Lightweight BPT. Instead of calling the API directly in your Screen Action or Service Action:

• Save the API input parameters into a "Queue" entity.
• Use an Entity Action to trigger a Light Process.
• Inside the process, call your REST/SOAP API.
• If it fails, do not use Sleep. Instead, calculate your jittered wait time and use the Wait activity or update a "NextRun" attribute on your queue record and let a timer/process pick it up.

Hello guys.

Thanks for the suggestions. I thought about controlling the retries using a table. But the application has too many users, like 50.000 or more and they could request the API at the same time. I need to consider this while thinking on an approach like this. Even if I have a clean up after an API sucess call, the database could overload. But it´s a thing that I need to consider.

Thanks again.

Alex Lima.

In OutSystems, implementing retry with jitter without using extensions is possible, but using Sleep() inside a synchronous action is not recommended because it blocks the application thread. Under load, this can quickly exhaust available threads and degrade performance.

A better OutSystems-native approach is to implement asynchronous retries with exponential backoff + jitter using Timers / BPT / queue tables.

Recommended Architecture (No Extensions)

1. Create a Retry Queue Entity

Example: ServiceRetryQueue

Fields:

• Id
• RequestPayload
• RetryCount
• MaxRetries
• NextRetryAt
• Status
• LastError

This table acts as a retry scheduler.

2. Call the Service Normally

When calling the REST/SOAP integration fails (timeout or exception):

1. Check RetryCount < MaxRetries
2. Calculate Backoff + Jitter
3. Store a record in ServiceRetryQueue

Create a Timer that runs every 1–2 minutes.

Thanks,

Saicharan