Script Execution Timeout

We provide script timeouts to protect storefronts. For example, if you accidentally create an endless loop, the loop can cause massive thread exhaustion and require a restart of the instance.

The Script pipeline node has a Timeout input parameter that controls how long a script can run. If the length of the script duration is longer than the timeout value, the script execution engine terminates the script. By default, the timeout value is 30 seconds. You can increase this value to 5 minutes for storefront requests and up to 60 minutes for job pipelines.

The max debugging timeout is 30 minutes. Therefore, if a script stays on a breakpoint for more than 30 minutes, the script is terminated. When you have a script debugger session running, the timeout value for all storefront and job requests is automatically increased to 5 minutes. This increase ensures that you have adequate time to step through your script without the script engine terminating your script.

Scripts in templates have an automatic timeout of 5 minutes. If you accidentally create an endless loop in a script, the script is automatically terminated and the timeout is logged.

Script Timeout for Jobs

You can render a template using dw.util.Template from a script. In that case, the general timeout for storefront scripts of 5 minutes is used if the script is used in a job. If you have a job that uses templates to render results, the jobs times out after 5 minutes, unless a higher timeout is configured. For jobs based on the deprecated job framework, the timeout configured at a Script node is applied. For jobs based on the new job framework, the timeout configured for the calling job step is applied.

Viewing Global Timeouts

You can view the global timeout that is applied for scripts that don't use the service framework. You can also specify a timeout as part of a function call.

To view the global timeout:

Select Administration > Global Preferences > Global Timeouts.
On the Global Timeouts page, view the default HTTP timeout for both connection and socket timeouts for HTTPClient calls outside of a job. Also view the default connection and socket timeouts for web service calls that don't use the service framework for either the storefront or jobs.

If you are having difficulty with scripts timing out while calling a third-party system or service, you can contact Customer Support to change the timeouts temporarily. However, we recommend using the service framework, which has multiple monitoring and management features for web services. If you are not ready to implement the service framework, you can configure time outs for HTTPClient or FTPClient as part of the function call.