Schedules

There are two ways to run something at set times. A Camel integration starts its route with Camel’s own timer: or quartz: component. A schedule document runs a command on an agent, such as curl for a URL, a script or any program the agent’s host has, and you write no route for it.

A route on a timer or a cron#

A timer starts the route at a fixed interval:

- route:
    from:
      uri: timer:tick?period=60000
      steps:
        - to: "{{erp-url}}/api/invoices/pending"
        - to: direct:transform

Camel’s quartz: component starts it on a cron. The cron has six fields, starting with the seconds:

- route:
    from:
      uri: quartz:payroll/nightly
      parameters:
        cron: "0 0 2 * * ?"
        trigger.timeZone: UTC
      steps:
        - to: direct:run-nightly-payroll

A polling route like these should run in one copy at a time when two agents run the integration. One copy at a time shows how.

A schedule that runs a command#

A schedule has a cron, a command and its arguments:

apiVersion: weik.io/v1
kind: schedule
metadata: { name: nightly-cleanup, project: finance }
spec:
  cron: "0 0 2 * * ?"
  command: bash
  args: ["-c", "/var/lib/weikio/scripts/cleanup.sh"]

weikio init nightly-cleanup --kind schedule writes a schedule that runs bash -c with an echo at 02:00 UTC, with a comment where your own script goes. Apply and deploy it like any integration:

$ weikio apply -f ./finance/schedules/nightly-cleanup.yaml
$ weikio deploy finance/nightly-cleanup --env production

The agent runs the command on its own host, so give the schedule requirements when the script exists on some hosts only, such as requirements: { site: factory }. A schedule runs one copy at a time by default, so the command runs once even when two agents match.

What a run leaves#

Each run gets an ID that every log line of the run carries. The command’s standard output and standard error go into the deployment’s logs line by line, and the last line says how the command ended, such as The command exited with 0. or The command exited with 3: <standard error>. A command that couldn’t start says why in the operating system’s own words.

$ weikio logs finance/nightly-cleanup --env production --since 24h

Each run also publishes a run record into the environment’s event stream, with its start, its end, the command’s exit code and whether it failed, which other integrations can read and react to. The schedule’s page has a Runs section, and the Events page and weikio events list offer schedule runs as a family of their own:

$ weikio events list --env production --family schedule --integration finance/nightly-cleanup --since 24h --with-body

An integration that reads a schedule’s run records is a reader like any other, so weikio reader skip and weikio reader rewind take --schedule. A run record the hub didn’t store while an agent was cut off is kept on the agent’s host and published when the agent reaches the hub again, the oldest first. Run records have storage of their own in each environment, which weikio env set --runs-bytes changes. A schedule built before 2026.2.2 records its runs once a new version of it is built and deployed.

A run whose command failed counts as a failed message in weikio status, weikio metrics and the admin UI.

Run it now#

weikio invoke runs the command at once, outside the cron, and prints what it printed:

$ weikio invoke finance/nightly-cleanup --env production --endpoint direct:schedule

UTC, and the schedule in words#

Every schedule’s times are UTC. The admin UI shows a cron in words beside its expression, such as Every 30 seconds (0/30 * * * * ?, from close-cron). The cron can come from a variable, cron: "{{close-cron}}", so devtest and production run on different times. Then the page shows the name of that variable and says when an environment has no value for it.