Usage
Cronhoster has two halves, joined by the sync. On the client side you keep a local folder of plain JavaScript and work in it — authoring, editing and testing jobs. On the server side the runner takes the folder the client pushed up, discovers which files are jobs, and executes each on its schedule.
Server →
How the runner works: the schedule filename grammar, the single-instance mutex, the script module contract, and what happens each tick.
Client →
The local workflow: your cron folder, what syncs and what stays local, developing in place, and how a set of edits becomes live safely.
The name is the schedule
The only magic is in the filenames. A top-level file whose name matches the schedule
grammar is an entry point; it runs on the cadence its name declares. Nested files never run on their
own — they are libraries the entry points import. Prefix a name with _ and it is ignored
entirely, so you can keep work-in-progress in the same folder.
cron/
digest.every.30m.cron.js → every 30 minutes
backup.daily.0300.cron.js → daily at 03:00 (UTC)
sweep.hourly.15.cron.js → at :15 past every hour
ping.every.30s.cron.js → every 30 seconds
lib/format.js → supporting module (imported, never run)
_draft.every.10s.cron.js → ignored (leading _ = local only)The full grammar, with every unit and range, lives in the Schedules reference. Start with the server to see how a tick turns into a running process.