# Delay in script execution on the OnChange feature

**URL:** <https://forum.inductiveautomation.com/t/delay-in-script-execution-on-the-onchange-feature/88865>\
**Category:** Ignition\
**Tags:** perspective, scripting\
**Created:** [April 16, 2024, 7:27am UTC](https://forum.inductiveautomation.com/t/delay-in-script-execution-on-the-onchange-feature/88865 "2024-04-16T07:27:29Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [April 16, 2024, 11:46am UTC](https://forum.inductiveautomation.com/t/delay-in-script-execution-on-the-onchange-feature/88865/4 "2024-04-16T11:46:54Z")

</div>

> [@Michal\_Goralczyk](#):
>
> recently started using much more complex scripts on tags could this be the cause?

Absolutely.

The thread pool size, by default, is three. That is, once three tag event scripts are running, or sleeping, or waiting on a network reply, all other tag events have to wait.

The pool size can be reconfigured to be larger, and that is reasonable for very large systems, but tag events should still be designed to execute as near instantly as possible, with only gateway-local information.

Any tag change script that needs to perform anything complex needs to be in a project-based gateway tag change event, not an event defined on the tag.

Algorithms that need delays must be implemented as state machines via gateway timer events.

---

_[View the full topic](https://forum.inductiveautomation.com/t/delay-in-script-execution-on-the-onchange-feature/88865)._