Caution
By default, wincron runs jobs as the highly privileged NT AUTHORITY\SYSTEM account, which grants full administrative control but lacks a standard user profile or PATH. Proceed with care, and consider using the user=NAME parameter to run jobs with reduced, per-user privileges (see below).
usage: wincron <command>
commands:
list print jobs from the crontab file
edit open the crontab file in an editor, then validate it
validate check the crontab file for errors
run run the scheduler in the foreground
install install the Windows service
uninstall remove the Windows service
start start the service
stop stop the service
version print the wincron version
The service commands need an elevated shell. run runs the scheduler in the current console (Ctrl+C to stop) and mirrors the log to stdout.
Run install.bat. It self-elevates, builds wincron.exe if not already present (requires Go; otherwise use a release zip), installs to %ProgramFiles%\wincron, and starts the service. The service starts at boot and is restarted by Windows on failure (after 5, 30, then 60 seconds). Upgrading over an existing install asks for confirmation first and keeps your crontab.txt.
To remove the service and files, run the uninstaller generated by the installer:
"%ProgramFiles%\wincron\uninstall.bat"It self-elevates, stops and removes the service, and deletes only wincron's own files. crontab.txt is kept, so the folder stays until you delete it; a later install picks the jobs up again.
Numeric 5-field cron expressions, named aliases in the month and day-of-week fields, and nicknames:
# minute hour day-of-month month day-of-week command
0 5 * * 1 tar -zcf C:\backups\home.tgz C:\Users
0 9 * jan-mar mon-fri report.exe
@daily backup.exe
@reboot foo.exe
A step on a bare value runs to the end of the field (5/3 = 5, 8, ..., 59).
When both day-of-month and day-of-week are restricted, a day matching either one runs the job (0 0 13 * 5 = every 13th and every Friday). As in standard cron, a field starting with *, such as */2, counts as unrestricted, so 0 0 */2 * 1 runs only on Mondays that fall on odd days.
@reboot runs once each time the scheduler starts (boot, service restart, or foreground run), not when the crontab is edited.
crontab.txt lives next to the executable (%ProgramFiles%\wincron\crontab.txt for a service install). Changes are picked up within a minute, keyed on the file's modification time (an edit that preserves the mtime is not noticed). A file with an error keeps the previous jobs and logs the problem; a missing file means no jobs until it appears.
wincron.exe edit opens it in %EDITOR% (Notepad if unset; a single executable with no arguments) and validates on save. For a service install this needs an elevated shell.
Commands run with cmd.exe /C: pipes, redirection, &&, and batch files all work. Unlike classic cron, % is not special, so %VAR% expands as usual. The working directory is the service's (System32), so use absolute paths; user= jobs run in the user's profile directory instead.
A job and everything it spawns are terminated as a group when it finishes, so start /b foo.exe leaves nothing behind; design jobs to run to completion, not to detach long-lived processes. On service stop, running jobs get 20 seconds to finish before being terminated.
BACKUP_DIR=C:\backups
0 5 * * 1 backup.exe %BACKUP_DIR%
Names must match [A-Za-z_][A-Za-z0-9_]*; whitespace around the name and value is trimmed. Values are literal: quotes are kept (NAME="x" gives the job "x", quotes included), and %OTHER% inside a value is not expanded; cmd.exe only expands %...% in command lines. SHELL, HOME, MAILTO, and TZ have no special meaning here: jobs always run under cmd.exe in local time, and output goes to the log, never to mail.
* * * * * user=foo command runs the job with that user's full profile, PATH, and environment, in their profile directory. Names match case-insensitively, as foo or DOMAIN\foo; quote names with spaces: user="Jan Noguer" (single or double quotes). Crontab NAME=value lines still apply on top of the user's environment.
Important
The user must already be logged in when the job triggers, otherwise the run is skipped and logged. A disconnected session (fast user switching, a dropped remote session) counts as logged in; an active session is preferred.
user= jobs require the scheduler itself to run as SYSTEM, the normal service install. A foreground wincron.exe run from a regular console skips them.
The tokens after the schedule are job options only while they start with user=, timeout=, or overlap= (case-insensitive); run a command whose first word starts with one of those through cmd /c. A standalone USER=name line is an environment assignment, not a user field. crontab.txt remains the privilege boundary: jobs default to SYSTEM, so only administrators should be able to edit the file.
Tip
Get-LocalUser lists the accounts on the machine.
0 * * * * timeout=5m overlap=no slow.exe
timeout= terminates the job and everything it spawned once the duration passes; the value needs a unit (30s, 5m, 1h30m). overlap=no skips a start while the previous run of the same job is still going; a job is identified by its line's text, so edits that only move it keep the tracking. Both sit with user= between the schedule and the command, in any order. Without them a job runs unbounded and concurrent copies are allowed.
Job starts, captured output (up to 64 KB per run), and exit statuses are written to wincron.log next to the executable (mirrored to stdout with run), or to the absolute path in the WINCRON_LOG environment variable (set machine-wide for the service). The log rotates at 10 MB, keeping one previous file as wincron.log.1. If the service fails before the log file is usable, the error is reported to the Windows event log under the wincron source.
If the scheduler wakes up late (machine asleep, heavy load), each job due during the missed window is started once (not once per missed minute), and minutes missed more than 60 minutes ago are skipped entirely.
Schedules follow local wall-clock time: during daylight-saving changes, jobs inside a skipped hour do not run that day, and jobs inside a repeated hour run twice. Likewise, if the system clock is set back, scheduling resumes from the new time and the repeated minutes run again.