Strange behaviour CRON Expression (SOLVED)

Hi All,

I’ve observed a strange behaviour when comes to some types of CRON Expressions. Consider the following:
I want a task to be executed the first Saturday of every month. The CRON expression that I came up with is 0 0 4 ? * 6#1 *, and, fair enough, the Orchestrator translated it to correct wording: Capture

The problema is that the process keeps being executed on the first Friday of the month!

Has anyone encountered a similar behaviour?



Can you check what is the start day of week. Based on that also it will vary.
Usually the start day of week will be Sunday.

Please try the below. I hope the start of the week is Sunday

0 0 4 ? * 7#1 *

Hi Kavi,

That expression actually returns a message of error. Yes, the week starts by Sunday, but then the correct expression would be: 0 0 4 ? * 0#1 *. Again, the Orchestrator translates it correctly as:

But as you can see also in the image, it is clear that internally it is not interpreting the expression that the job is going to be executed on Sunday, but in 19h ( that is, Saturday at 4 PM).

Hi @RockSolid,

Have you had any progress or resolution on this? What version of Orchestrator are you using?
I observed the same for one of my clients using 2018.2.6 who flagged their process was running on the wrong day. It was set to 0 0 0 ? * 6#3 which should resolve to a Saturday midnight , but was running on a Friday midnight.

I have raised a support ticket pending a response.

Hi Ryan,

I’m using 2018.1.1. No progress so far. We are migrating to 2018.4.2 in a few weeks, so I hope that solves the issue. Please, poste the solution if you manage to solve it together with support.


I managed to find a workaround solution.

You can express a weekday in CRON using the day name abbreviation (e.g. FRI, SAT, etc). So my: 0 0 0 ? * 6#3 became 0 0 0 ? * SAT#3

Similar expressions are available for months too.

This seems to be recognised by Orchestrator and resolves correctly. From the testing I have done, is the only generator found that produces expressions that are interpreted correctly by Orchestrator.

I will update if anything additional comes from support.