Orchestrator user guide

DELIVERY:

Last updated Nov 3, 2025

Creating a time trigger

Important: Time triggers that are created at design-time using time trigger activities can be further configured at process-creation time, in Orchestrator, as these types of triggers are identified as package requirements.

Read Managing package requirements > Adding time and queue triggers to find out more.

In a folder, navigate to Automations > Triggers and on the Time Triggers page, click Add a new trigger. The Create Time Trigger page is displayed.
From the Process Name drop-down menu, select the process you want to configure a time trigger for.
In the Name field, add a name for the trigger to easily identify it.
From the Job Priority drop-down menu, select the priority of the job. The default value is Inherited, meaning that the job priority is the same as the one defined for the selected process.
From the Runtime type drop-down menu, select the runtime used to execute the jobs that are launched by the trigger.

On the Execution Target tab, select your jobs' allocation mechanism and execution target.

Description
Dynamic allocation	Allocate Dynamically Dynamic allocation with no explicit account and machine selection allows you to execute a foreground process multiple times under the account and machine that become available first. Background processes get executed on any account, regardless if it's busy or not, as long as you have sufficient runtimes. Using the Allocate Dynamically option you can execute a process up to 10000 times in one job.
	Account The process is executed under a specific account. Specifying only the account results in Orchestrator allocating the machine dynamically. Specifying both the account and the machine template means the job launches on that very account-machine pair.
	Machine The process is executed on one of the host machines attached to the selected machine template. Specifying only the machine template results in Orchestrator allocating the account dynamically. Specifying both the account and the machine template means the job launches on that very account-machine pair. Note: Make sure the required runtime licenses to execute the job are allocated to the associated machine template.
	Hostname After selecting a machine template, the Hostname option is displayed, allowing you to select the desired workstation/robot session to execute the process. All available sessions in the active folder are displayed, either unconnected, disconnected, or connected. Note: Only unattended runtimes can be used to configure the mapping. Make sure the required runtime licenses to execute the job are allocated to the associated machine template.
Select valid account-machine mappings	The process can be executed on specific account-machine pairs. Learn more about account-machine mappings. Note: A warning is displayed upon selecting a hostname that is not active (i.e., with the Unresponsive or Disconnected status). Accounts part of mappings that are employed in triggers cannot be deleted or unassigned from the folder the trigger resides in. Make sure the account is not set as an execution target in a trigger so you can delete them.

Note: A warning is displayed upon selecting a hostname that is not active (i.e, with the Unresponsive or Disconnected status). Jobs scheduled to be executed by the inactive session remain in a Pending state until the corresponding connection to Orchestrator is made.

To acknowledge your selection of the inactive hostname, click Confirm.

To go back and select another hostname, click Cancel.

Configuring the same trigger with the same account-machine mapping, but with an additional hostname selection doubles the number of jobs to be executed.

For example, say you configured a trigger T1 with the account A1 mapped to the machine template MT1. A number of ten jobs are queued for execution in this configuration.

Later on, you configure the same trigger T1 with the account A1 mapped to the machine template MT1, but now you also select a hostname H1. The same ten jobs are queued again for this case, as Orchestrator interprets the configuration as new.

On the Arguments tab, provide values for input arguments if your process has any. More details about input and output arguments.
From the Timezone drop-down menu, select the time zone according to which the trigger is to be set off.
Note:
- The trigger time zone is not dependent on the tenant time zone. You can set a different time zone for your time trigger execution.
- Locations that use daylight saving time (DST) are listed in their UTC offset. The UTC offset is not increased when DST is in effect. For example, during the DST period, the London time zone is displayed as UTC+00:00.
- You do not have to adjust the time zone in order to account for DST, as Orchestrator's schedule mechanism automatically takes into account when launching a job. A job scheduled to run at 12:00 runs at 12:00 both in winter and summer.
Select the execution frequency of the trigger. The available options are:
- Minute by minute - Choose the number of minutes that should elapse between trigger executions. Example: Every 5 minute(s).
- Hourly - Choose the number of hours that should elapse between trigger executions, as well as the minute that should mark the start of a new execution. Example: Every 2 hour(s) at 20 minutes past.
- Daily - Choose the number of days that should elapse between trigger executions, as well as the time when a new execution should start. Example: Every 4 day(s) at 12:30 PM.
- Weekly - Choose the specific weekday and time when you want the trigger to execute. Example: Monday at 11:45 AM.
- Monthly (day of month) - Choose the number of months that should elapse between trigger executions, as well as the day and the time when a new execution should start. Example: Every 2 month(s) at 11:30 AM, running on the last working day of the month.
- Monthly (day of week) - Choose the number of months that should elapse between trigger executions, as well as the weekday and the time when a new execution should start. Example: Every 2 month(s) at 11:30 AM, running on Mondays.
- Advanced - Set a custom cron expression. For details, see the Using Cron Expressions page.
Orchestrator uses an open-source library to parse and display cron descriptions, which can be found here.
Note:
Cron expressions can be used in combination with non-working days. This means that, if a trigger is configured via a cron expression to run on a day that falls on an excluded date, that day is skipped, and the trigger is rescheduled for the next available day, and so on.
Choose the frequency with which you want the trigger to execute, in minutes.
Important:
The cron standard employed by our cron expressions uses a time system based on 60 minutes to an hour. This means that the only way it can execute a trigger at the exact interval configured in the Repeat every field is if the value of that interval is a divisor of 60. Otherwise, the recurrence will not entirely abide by the number of minutes in that field, thus causing execution discrepancies. To avoid this, we recommend adjusting your trigger settings or using event triggers.
Example: You set a trigger to be executed every 21 minutes, and you start a job at 9:00. This renders the following execution schedule:
- The first job starts at 9:00.
- The second job starts at 9:21.
- The third job starts at 9:42.
- The fourth job starts at 10:00.
The reason why the fourth job starts after 18 minutes instead of 21 is that the cron component matches every 21^st item from a set of minutes between 1 and 59. In this example, these items are 00, 21, 42.
From the Non-working days restrictions drop-down menu, select a non-working days calendar, if you want your trigger to stop firing on certain non-business days. More details about non-working days.
Turn on the Schedule ending of job execution toggle to select a job termination strategy.
Note:
- The amount of time specified here elapses according to the specifications, even if the job is queued. For example, if you schedule a job to run at 1 p.m. and set it to stop after 20 minutes, the job stops at 1:20 p.m. even if it had stayed in a queue until 1:15 p.m., and then started.
- The Schedule ending of job execution options of a trigger are preserved for manually started jobs.
For example, say you created the trigger T1 and you activated the following job ending schedules:
- Schedule ending of job execution:Stop a job after 10 mins
- Schedule automatic "Kill", if the job does not stop:Kill job after 2 mins
  
  On the Automations > Triggers page, when you click Start a Job Now for the trigger T1, the Start Job page opens with the job ending schedules already applied, the same ones you configured when you created the trigger.
Example: If you schedule to stop a Pending or Running job after 2 hours and also configure to kill the same job after 3 hours, the job will be killed after 5 hours. This happens because, first, the signal is sent to Orchestrator that the job was indeed stopped after 2 hours. Once the signal has been received, the kill job action is triggered to occur in 3 hours, thus resulting a total of 5 hours.
- Select Stop from the drop-down - attempts to gracefully end the execution after the defined time interval has passed since the job is stuck in a Pending or Running state (set the time to a minimum of 1 minute, maximum of 10 days, 23 hours and 59 minutes);
  Example: Orchestrator will attempt to stop jobs that have been stuck for at least 10 minutes in Pending or Running.
  Figure 1. Scheduling the ending of job execution
- Select Kill from the drop-down - attempts to forcefully end the execution after the defined time interval has passed since the job is stuck in a Pending or Running state (set the time to a minimum of 1 minute, maximum of 10 days, 23 hours and 59 minutes);
  
  Example: Orchestrator will attempt to kill jobs that have been stuck for at least 10 minutes in Pending or Running.
- Select Stop from the drop-down and enable the If the job does not stop, kill it option - attempts to gracefully end the execution after the defined time interval has passed since the job is stuck in a Pending or Running state and then attempts to forcefully end it after the defined time interval has passed since the job is stuck in a Stopping state (set the time to a minimum of 1 minute, maximum of 10 days, 23 hours and 59 minutes).
  
  Example: Orchestrator will attempt to stop jobs that have been stuck in Pending or Running for at least 10 minutes. If the termination does not happen, Orchestrator will attempt killing those jobs that have been Stopping for at least 20 minutes.
Turn on the Schedule automatic trigger disabling toggle, and enter the date and time when the trigger is to be disabled. The selected time zone influences when the time trigger gets disabled.
Turn on the Generate an alert if the job is stuck (in pending or resumed status) toggle, and set the acceptable duration for the job to remain in the pending or resumed status. The minimum configurable duration is one minute. The maximum configurable duration is eleven days. If the job exceeds the configured duration, an "Error" severity alert pop-up informs you about it with the following text: "N jobs for #process {process_number} have been pending or resumed for more than X hours and Y minutes.", where:
- N - is the number of jobs that triggered the alert;
- {process_number} - the process identifier;
- X - the configured number of hours the job exceeded while having the pending or resumed status; Days are converted to hours.
- Y - the configured number of minutes the job exceeded while having the pending or resumed status.
Turn on the Generate an alert if the job started and has not completed toggle, and set the acceptable duration for the job to complete. The configurable duration is minimum one minute and maximum eleven days. If the job exceeds the configured duration, an "Error" severity alert pop-up informs you about it with the following text: "Job for #process {process_number} has been pending been running for more than X hours and Y minutes.", where:
- {process_number} - the process identifier;
- X - the configured number of hours the job exceeded while trying to complete; Days are converted to hours.
- Y - the configured number of minutes the job exceeded while trying to complete.

Turn on the Set execution-based trigger disabling toggle if you would like to control when the trigger is disabled once a job fails. This toggle reveals two options:

Option	Description
Disable when consecutive job execution fail count	The trigger is disabled after the number of failed executions you choose for this setting. You can choose a value between 1 and 100. The default is 1, meaning that the trigger is disabled after 1 failed launch. Stopped jobs are not counted towards this value.
Grace period on disabling the trigger (days)	The number of days to wait before the trigger is disabled after the first failure of a job. You can choose a value between 0 and 30. The default is 0, meaning that the trigger is disabled as soon as the number of job executions set in the field above is reached for the current day.

Note:

If you are on the Community licensing plan and you choose a Cloud - Serverless runtime for the underlying process, the Set execution-based trigger disabling option is automatically enabled, with the following default values (the fields are read-only):

Disable when consecutive job execution fail count is set to 10.
Grace period on disabling the trigger (days) is set to 0.

To keep the same account-machine context configured for starting the job, check the Keep Account/Machine allocation on job resumption box. This optimizes your license and resource usage.

Was this page helpful?

PREVIOUSManaging triggers

NEXTCreating a queue trigger

Support and Services

Get The Help You Need

UiPath Academy

Learning RPA - Automation Courses

UiPath Forum

UiPath Community Forum

Trust and Security

Cookies Policy