Schedules and Jobs
Schedules​
A schedule runs one report on a cron expression. Schedules belong to the report and execute on the agent, using the agent's scheduling.timezone.
Reporting → Reports → (a report) → Schedules → New:
| Field | Purpose |
|---|---|
| Cron expression | When to run — 0 6 * * 1 is 06:00 every Monday |
| Parameters | Values bound on every run of this schedule |
| Distribution | Which channels receive the output (overrides the report default) |
| Enabled | Pause without deleting |
The same report can carry several schedules with different parameters — one per region, say, each delivering to a different distribution list. That is usually cleaner than duplicating the report.
Timezones​
Schedules fire in the agent's configured timezone, set once in agent.yaml:
scheduling:
timezone: Europe/London
maxConcurrentRuns: 3
Set this to the timezone your business reports in. If you run agents in several regions, each fires in its own local time — which is normally what people want from "the Monday morning report", but worth knowing when you are comparing run times across sites.
Concurrency​
maxConcurrentRuns caps how many runs execute simultaneously on that agent. Runs beyond the cap queue rather than failing. Raise it if reports are backing up and the database can take the load; lower it if scheduled reports are competing with production traffic.
Offline behaviour​
If the agent loses its connection to Rynko, schedules keep firing against the locally cached report definitions. Documents are generated and distributed as normal. Run records queue locally and sync when the connection returns, so run history is complete rather than gapped.
Jobs​
A job runs several reports together as one unit. Reach for one when a set of reports belongs to the same business event — a month-end pack, a nightly operations bundle, a distribution to one recipient list that happens to need six documents.
Reporting → Jobs → New:
- Add the reports the job should run
- Give each report its own parameter values — a job can pass different arguments to each member report
- Set the job's schedule and distribution
Running a job produces one job run containing a run per report. If one report fails, the job records the failure without discarding the reports that succeeded.
Jobs vs. schedules​
Use a schedule when one report needs to run unattended.
Use a job when several reports should run and be delivered as a set, and you want a single record of whether the set succeeded.
Triggering from outside Rynko​
For orchestration that already lives elsewhere — Airflow, Control-M, Windows Task Scheduler, a deployment pipeline — skip Rynko's scheduler and call the agent directly:
rynko-run --report month-end-pack --params '{"period":"2026-09"}'
The CLI exits non-zero on failure, so it composes with whatever retry and alerting your scheduler already provides.
Systems that cannot run the CLI can trigger a report over HTTP with a run key.