Timers in OutSystems are a powerful mechanism for scheduling background tasks that need to run periodically or after specific events. This article provides an in-depth technical overview of how timers work in On-Premises installations of OutSystems (post version 11.24), including their concurrency model, thread management, scheduling mechanism, error handling, and best practices for high-load environments.

1. Timer Execution Model

OutSystems timers are executed by the Scheduler Service, a dedicated background Windows Service installed on each front-end server in an On-Premises environment. This service is responsible for checking whether any timers are due to run and initiating their execution.

Timers are not triggered by SQL Server Agent jobs, Hangfire, RabbitMQ, or Windows Task Scheduler. Instead, the Scheduler Service performs internal polling of the platform's system database every few seconds to check for timers whose Next_Run field indicates they are due.

When a timer is ready, the Scheduler makes an internal HTTP call to the application server to invoke the timer logic as a background execution. Each front-end node running the Scheduler Service can pick up and execute timers in parallel.

2. Concurrency Limits

By default, each Scheduler Service instance can run up to 3 different timers concurrently. These timers must be uniquely named (you cannot run the same timer in parallel multiple times on the same node). This concurrency limit can be adjusted using the OutSystems Configuration Tool in self-managed installations.

If a timer is marked as multi-tenant, it can run concurrently for different tenants even though it's technically the same timer. This is useful for isolated processing in multi-tenant applications.

3. Thread Usage

Each timer consumes a dedicated execution thread. By default:

• 3 threads are reserved per node for timer executions.

• Additional threads are allocated for BPT (Business Process Technology) processes and Light Processes.

Threads for timers are managed separately from those for web requests or asynchronous processes to avoid resource contention.

4. Scheduling Mechanism

Timers are configured with a recurrence schedule (e.g., daily, hourly) and priority (Low, Normal, High). The Scheduler Service fetches due timers from the database, sorts them by priority and scheduled time, and queues them for execution.

Timers that cannot be run immediately due to thread saturation are placed in a pending queue. They will be executed as soon as threads become available.

5. Execution and Compilation

Timer logic is developed in Service Studio as server-side actions and compiled during application deployment. The compiled logic resides in the server's application runtime (e.g., within IIS for .NET stack).

Only the metadata such as scheduling info and execution logs are stored in the system database. When triggered, the timer's module is loaded into memory if not already, and the server executes its logic.

6. Transactions and Error Handling

Timers execute within a database transaction scope. If an uncaught exception occurs or the timer times out, the entire transaction is rolled back.

OutSystems retries failed timer executions up to 3 times by default, with increasing delay between retries. The number of retries can be configured through the environment settings in Service Center.

Developers can optionally commit partial results using CommitTransaction() if needed, though this breaks atomicity and must be used with caution.

7. High Load and Performance Considerations

If 20 or more processes (timers or BPT) are running simultaneously:

• Timers are still processed independently, using their own thread pool.

• The Scheduler queues excess timers and executes them when resources free up.

• Performance may degrade if CPU, RAM, or DB connections are maxed out.

Best Practices:

• Stagger timer schedules to avoid simultaneous execution.

• Use Deployment Zones to dedicate specific nodes for timer-heavy workloads.

• Monitor execution logs and environment health in Service Center.

• Keep timer logic efficient; avoid long-running operations.

• Avoid triggering too many tenants’ timers simultaneously in multi-tenant apps.

• Do not forget awake pattern
  

8. Conclusion

OutSystems timers offer a robust background task execution model suitable for both periodic and on-demand logic. Understanding how the Scheduler Service, concurrency limits, and database coordination work helps ensure reliable performance even under high load. With the right configuration and coding practices, timers can become a key asset in managing background operations in your OutSystems applications.