Reference

The lookup tables the usage guide points at. A cron folder is plain JavaScript; the only magic is the entry-point filenames. These pages spell out that grammar, the module contract a script fulfils, the commands that drive the client and server, and every file that can live in a content root — so each guide page can link to one source of truth.

Schedules →

The definitive filename grammar: every interval unit, every clock token, and the valid range of each — plus base-name extraction and the mutex.

Scripts →

The script module contract: what a cron script may export, the ctx it receives, success and failure semantics, and how require resolves.

Commands →

The client CLI flags and the server-side service commands — starting, restarting and inspecting the API and runner, and pulling logs back.

Files →

The content-root layout: naming rules, the ignore rules, supporting files, and the _env.json secrets file — each path shown as a pattern.

The shape of a content root

One flat script directory, mirrored whole. Top-level schedule-named files are jobs; everything else rides along as supporting code.

cron/                          your content root, mirrored as a whole
  digest.every.30m.cron.js     entry point → runs every 30 minutes
  backup.daily.0300.cron.js    entry point → runs daily at 03:00 UTC
  report.hourly.00.cron.js     entry point → at :00 past every hour
  report.hourly.30.cron.js     entry point → same base name, at :30 too
  lib/                         supporting modules, imported by jobs
    format.js
    mailer.js
  _draft.every.10s.cron.js     ignored (leading _ = local only)
  _env.json                    ignored secrets, read by the runner
  .gitignore                   ignored (dotfile)

The Files page breaks this down path by path; the Schedules page is the grammar behind the entry-point names.