Schedule allows you to specify the schedule on which your scheduled search should be run. If you want to write a cron expression to control the search scheduled, select Use cron expression. This creates a cron expression in the background and enables the Schedule field option.

The Schedule field must be populated with a UNIX cron expression, as known from the crontab file found in many UNIX-like systems. There are many online tools to help you generate UNIX cron expressions that you can use if you need help writing up an expression for your use case.

For more information, see Cron Schedule Templates

Alternatively, you can use the Simple schedule configuration option to set up a scheduled for your search with the desired frequency — use the Frequency drop-down to select how frequently the scheduled search runs. If you choose weekly or monthly, you have the option to choose days of the week or days of the month on which the scheduled search runs.

The Time option is available when selecting the Simple configuration, to set the time at which the scheduled search starts and the timezone in relation to UTC time.

The Coordinated Universal Time(UTC) offset defines the temporal offset from UTC in which the search is scheduled. For instance, with a schedule:

0 6 * * *

With an offset UTC+01:00, the search will be scheduled for 5AM at UTC.

This option configures how long scheduled searches running on @ingesttimestamp should wait for various error conditions. This waiting time covers any possible ingest delays, retry due to errors or downtime, and retry due to query warnings about missing data. By setting a Max wait time, correctness of the results may improve. Setting Max wait time to zero or a low value returns the results faster, but correctness of the results may be reduced.

Option available when using @timestamp as the timestamp option for your scheduled search. If LogScale is down or an error prevents an action from being triggered, you will miss searches that would have otherwise been scheduled and executed. When it again becomes possible for schedule searches to run and have them trigger actions, LogScale will attempt to backfill searches that were missed previously.

The backfilling behavior is only available for scheduled searches running on @timestamp and depends on the value given to the backfill limit, which determines how many missed searches will be executed before any new searches are scheduled.

For example, if you schedule a search every hour:

0 * * * *

and LogScale is down between 10:30 and 14:15, this means that the searches at 11:00, 12:00, 13:00 and 14:00 would be missed.

Executing the most recent 'missed' search is not considered backfilling, as this can also occur under normal operation if there is a slight delay within LogScale. Thus, if the backfill limit is set to 0, as per default, only the search at 14:00 will be executed at startup.

If you increase the limit to 1 you would start off by executing the search scheduled at 13:00. If you increase the limit to 2 you start with the search at 12:00. And if you increase the limit to 3 you start with the search at 11:00. Increasing the value of the backfill limit beyond this point will not have any effect in this example. Missed searches are executed in sequence from oldest to newest.

The backfill limit may not exceed the global maximum backfill limit.

Use Delay run to set a delay when using @timestamp to make sure the search run does not miss late-arriving events.

When calculating the delay, this should be the sum of ingest delay outside of LogScale (before the events enter LogScale) and ingest delay inside of LogScale over all events relevant for the scheduled search. For more information, see General information about ingest delay.

LogScale always attempts to run a search exactly according to schedule. This makes scheduled searches predictable, but also risks that many scheduled searches will be configured to run at the same time, which might cause delays. If there are multiple scheduled searches running, it is a good idea to spread them out over time, so that they are not running all at the same time.

For example, it is common to schedule many jobs for midnight, if they are to be run daily. But if you experience delays in search execution because of a sudden high search load, try to space the searches out over a larger span of time.

One way to automate this, rather than manually tracking individual requests, is to use the H notification. Using H for minutes in the cron expression, allows LogScale to automatically choose the number of minutes past each hour that a scheduled search will be run.

Using this notation can be an effective way spreading out the execution of scheduled searches without having to monitor and track each scheduled search manually. The notation also makes it easy to copy and duplicate scheduled searches.

This method is only appropriate if you do not need to explicitly control the search window. Because H automatically chooses a minute, the search window will be determined by the chosen figure. For example, if you use the H notation to run the search from 24 hours ago to now, and the search runs at 0:48, then the search window will be from 0:48 yesterday until 0:48 today.

If you decide to run a search on another schedule, but wish to keep the same search window, you need to update start and end on your scheduled search. For instance, if your search was running at midnight and searching through the previous day, you would have configured the interval parameters as start=24h and end=now. But if you need to reschedule this search run at 3AM instead, you would have to update the interval parameters as start=27h and end=3h to search within the same 24 hour time window.