Schedules
There are many scenarios in which it is beneficial to run a Process on a regular cadence. Examples for such Process could include monthly budget reports, hourly inventory evaluation, and so on. Unmeshed currently supports cron expressions.
Video Guide: Schedules on Unmeshed
Cron expressions
A cron expression is a simple string that's used to describe repetition patterns. Unlike Intervals, crons have a fixed schedule and and don't take into account when the last execution completed. They can be useful in cases where there's a need for specific trigger times, such as with overnight batch processing, database upgrades, and so on.
Unmeshed uses Unix-cron, which comprises of the 5 fields shown below. The general notion is that the Process would trigger when the current time matches the time indicated by the expression.
* * * * * *
| | | | | |
| | | | | day of the week (0–6, starting from Sunday)
| | | | month (1–12)
| | | day of the month (1–31)
| | hour (0–23)
\ minute (0–59)
For example, for a Process to trigger every workday at 10pm, you would use 0 22 * * * 1-5. Roughly read as:
trigger every minute 0, hour 22, on days Monday-Friday. Asterisk (*) means that the field is unrestricted.
For additional examples, please check out the content on crontab.guru. It is an excellent resource for analyzing cron expressions.
Intervals (coming soon!)
Intervals configure how much time should pass between one completed execution and the next one. In other words, scheduling of the next run can only occur when the previous run has completed. This form of scheduling can be used in cases where Processes have unknown execution time, and it is desirable for executions to be spaced out.
Overlap policy
Cron expressions produce fixed schedules, meaning that Processes would trigger at specific times regardless of previous executions. This could lead to situations where Process runs are triggered while previous one(s) have not completed. And since Processes operate in an asynchronous environment, it is even possible that the second process would complete execution before the first (overlapping) one does. This is not necessarily unwanted behavior, but Unmeshed allows you to specifically configure this behavior when the new schedule is about to be triggered. By default, Unmeshed does not allow Process runs to overlap.
| Value | Default |
|---|---|
| AllowOverlap | ✔️ |
| DoNotOverlap |