Obtain the application vendor’s supported command, actual executable path and required runtime. Confirm server timezone and whether a previous run can overlap the next. Back up important data before scheduling a task that changes it.

1. Open Hosting Features > Cron Jobs. Review Cron Options for the shell, search path and monitored Mailto address.
2. Use the Simple or Advanced editor to enter the intended schedule. Check every time field rather than copying a schedule whose timezone or frequency is unknown.
3. Enter the command with absolute paths to its executable and script. If a working directory is required, use the application’s documented invocation.
4. Add the job and observe a controlled first run. Keep errors visible in email or a protected rotating log while validating it.
5. Confirm completion time and application results, then adjust scheduling to prevent unnecessary load or overlaps. Remove obsolete duplicate jobs.

For a temporary diagnostic job, first confirm that /usr/bin/printf is available to your account; use the executable path supplied by support if it differs. This command prints one line and changes no website or database data:

/usr/bin/printf 'Nabtech cron check completed\n'

For an illustrative daily run at 03:15 in the configured server timezone, the five cron fields are 15 3 * * *: minute 15, hour 3, every day of month, every month and every day of week. Enter these into the respective schedule fields, and select a nearer authorized test time if needed. Keep a monitored Mailto address and do not suppress output.

Confirm the line arrives after the expected run, then remove the diagnostic job. This tests scheduler execution and notification delivery, not the real application job. Verify the application command separately before enabling its production schedule.

The task should run once per intended interval, complete successfully and leave useful evidence of failures. A cron email alone is not proof the business operation completed.

Commands can work interactively but fail under cron because of a smaller environment, a different PHP executable or missing permissions. Check those differences before increasing frequency. Avoid suppressing all output until the task has been verified.

Not necessarily. A scheduled command can invoke a separate CLI executable. Verify its version and extensions independently of the web runtime.

• Selecting a PHP version for a SiteWorx domain
• Changing a SiteWorx database-user password
• Following SiteWorx web-server logs during a reproducible error
• Scheduling SiteWorx backups with retention

• InterWorx: Manage Scheduled Tasks Cron Siteworx