Scheduling tasks in Linux is traditionally done with the Cron Task Scheduler.  There are many online resources about cron, one of which is this site, https://www.vultr.com/docs/how-to-use-the-cron-task-scheduler/.  With Webmin, the task scheduling can be managed through the WebUI.  Details can be found here, https://doxfer.webmin.com/Webmin/Scheduled_Cron_Jobs.   Here is a simple scheduled task that reboots the Linux host daily at 1:30am.

30 1 * * * systemctl reboot -i

Scheduling this in Cron or through Webmin results in the same entry in the respective crontab file.

Some tasks are poorly designed, or implemented in a way that they weren’t intended for.  In those instances, the process can do some strange things.  This can result in a process hang, memory leak, or cascading processes that exhaust system resources, to name some examples.  Restarting those processes is a quick and dirty workaround, but by no means a fix.  This is where scheduled tasks can be leveraged.

13,28,43,58 * * * * node-red-restart

Some tasks don’t lend themselves well to automated scheduling, one of them being RTL433.  This particular example, https://www.cloudacm.com/?p=3501, would run for a period of time, but then stop for one reason or another.  Here is where Supervisor has been demonstrated to help keep tasks running, https://www.hagensieker.com/wordpress/2019/03/06/how-to-keep-rtl_433-alive-for-your-home-automation-using-supervisor/.  Depending on the extensive use of Supervisor, some might argue that each task have its own conf file with the command parameters contained in each.  Here is an example of a conf file located in this path, /etc/supervisor/conf.d/rtl443.conf.

[program:rtl433]
command=/bin/sh /home/local/Tasks/RTL433-MQTT.sh
autostart=true
autorestart=true
startretries=100
stderr_logfile=/var/log/rtl433/rtl433.err.log
stdout_logfile=/var/log/rtl433/rtl433.out.log

Everyone is free to do as they see fit, whether they see it that way or not, consequence is secondary.