Skip to content

Knowledgebase

Creating a scheduled command in Webmin

control-panels, servers

Create a recurring command in Webmin Scheduled Cron Jobs under the Unix account that owns the work. This is useful for maintenance and application tasks, but an overly privileged or overlapping schedule can cause repeated damage.

Check access and requirements

Obtain the application supported command and identify its runtime, working directory and required permissions. Check server timezone, expected duration and output handling. Confirm that the same task is not already scheduled by Virtualmin, a package or a systemd timer.

01 Create a scheduled command in Webmin

  1. Open System > Scheduled Cron Jobs and choose Create a new scheduled cron job. Select the intended Unix user in Execute cron job as.
  2. Enter the full command using absolute executable and script paths. Use the application supported working-directory setup and protected environment configuration rather than assuming your interactive shell settings will apply.
  3. Set the schedule deliberately and add a descriptive comment. Keep a new job inactive until you have reviewed the command if it can change production data.
  4. Configure useful output handling through cron mail or a private log with retention. Avoid sending secrets in command arguments or discarding every error during testing.
  5. Run a safe controlled test as the same user, then activate the schedule. Use the application locking or another tested mechanism to prevent overlapping executions when needed.
  6. Observe one scheduled run and confirm completion. Review who can edit the job, especially if it executes with elevated privileges.

Should I use Scheduled Commands for a repeating job?

Webmin distinguishes one-time Scheduled Commands from recurring Scheduled Cron Jobs. Choose the recurring module for an ongoing schedule and verify its saved timing fields.

Confirm the expected result

Check the actual output, exit result where available and application state at the expected time. Verify only one scheduler runs the task. Confirm logs stay private and do not grow without rotation.

Resolve setup problems

If the command succeeds interactively but fails under cron, compare PATH, current directory, environment and permissions. Do not change the execution user to root simply to suppress a permission error. Disable a harmful or duplicate schedule while investigating rather than repeatedly rerunning it.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support