Weik.io

Scheduled Tasks

Execute commands on a schedule using cron expressions

Scheduled Tasks run commands automatically at specified times using standard cron expressions.

Under the hood, when you create a Schedule, Weik.io generates an Apache Camel integration flow. This flow uses Quartz to handle the timing and the Camel exec component to run your command.

How It Works

You don’t need to manually configure Camel or Quartz. When you write a Schedule configuration:

  1. Weik.io saves your cron expression, command, and arguments.
  2. It automatically generates the Camel integration flow.
  3. It creates a NATS stream for the schedule.
  4. Quartz watches the clock and triggers the flow when the cron expression matches.
  5. An Integration Agent with matching requirements picks up the job and runs the command.

Writing a Schedule

You define schedules using a YAML configuration file.

apiVersion: weik.io/v1alpha1
kind: Schedule
metadata:
  name: webhook-test
  description: Call webhook every minute
spec:
  cron: "0 0/1 * * * ?"
  command: curl
  args:
    - "-X"
    - GET
    - "https://api.example.com/health"
  requirements:
    Environment: production
    Network: external

The Spec

  • cron (required): A 6-field Quartz cron expression.
  • command (required): The executable to run. This can be curl, python, node, bash, or any other binary installed on the target Integration Agent.
  • args (optional): A list of command-line arguments. These are passed exactly as you write them, in order.
  • requirements (optional): Key-value pairs that determine where this command runs.

Targeting Specific Agents

You usually don’t want a database backup script running on a random web node. You use requirements to route the schedule to the correct Integration Agent.

If your schedule looks like this:

requirements:
  Environment: production
  Datacenter: eu-west
  DatabaseAccess: "true"

It will only execute on an Integration Agent that started up with those exact capabilities. If no agent matches, the schedule won’t run.

Cron Expression Format

Schedules use Quartz cron syntax. Note that this requires 6 fields (seconds are included), which is different from standard Linux cron (5 fields).

* * * * * *
│ │ │ │ │ │
│ │ │ │ │ └─ Day of week (1-7 or MON-SUN)
│ │ │ │ └─── Month (1-12 or JAN-DEC)
│ │ │ └───── Day of month (1-31)
│ │ └─────── Hour (0-23)
│ └───────── Minute (0-59)
└─────────── Second (0-59)

Common Patterns:

  • 0 0/5 * * * ? - Every 5 minutes, at exactly 0 seconds
  • 0 0 0/1 * * ? - Top of every hour
  • 0 0 2 * * ? - Daily at 2:00:00 AM
  • 0 0 9 ? * MON-FRI - Weekdays at 9 AM

Examples

Nightly Database Backup

apiVersion: weik.io/v1alpha1
kind: Schedule
metadata:
  name: nightly-backup
spec:
  cron: "0 0 2 * * ?"
  command: bash
  args:
    - "/scripts/backup-database.sh"
  requirements:
    Environment: production
    DatabaseAccess: "true"

Run Python Sync Script

apiVersion: weik.io/v1alpha1
kind: Schedule
metadata:
  name: data-sync
spec:
  cron: "0 0 0/1 * * ?"
  command: python
  args:
    - "/opt/scripts/sync-data.py"
    - "--incremental"
  requirements:
    Environment: staging

Trigger an API Report

apiVersion: weik.io/v1alpha1
kind: Schedule
metadata:
  name: trigger-report
spec:
  cron: "0 0 8 * * MON-FRI"
  command: curl
  args:
    - "-X"
    - "POST"
    - "https://api.example.com/reports/generate"
    - "-H"
    - "Authorization: Bearer ${API_TOKEN}"
    - "-H"
    - "Content-Type: application/json"
    - "-d"
    - '{"reportType":"daily","format":"pdf"}'

Troubleshooting

If your schedule isn’t doing what you expect, check these first:

It never runs at all Make sure your cron expression has exactly 6 fields. Standard crontab generators online usually output 5 fields, which will fail here because Quartz requires the seconds field. Also, verify that an agent matching your requirements is actually online.

The command fails instantly The agent executing the schedule must have the executable installed. If you schedule a python script, the agent needs Python in its PATH. Test the command manually on the target machine first.

Arguments are being ignored or mangled Look closely at your YAML args array. Don’t write -X POST as a single argument. It needs to be two separate list items:

  args:
    - "-X"
    - "POST"

Schedules are stepping on each other If a script takes 10 minutes to run, don’t schedule it to run every 5 minutes. The system will start a second instance while the first is still going, which usually causes file locks or database deadlocks.

What’s Next