Schedules

A schedule ties a workflow or script to a cron expression and an environment. When active, Runner fires the schedule automatically at the specified interval and records every execution as a Run. You can also trigger a run manually at any time, regardless of whether the schedule is active or the cron expression has fired.

Your schedules

The schedule list shows all schedules in the current project. Each row displays the description and any executor tags, the status of the latest run, the next scheduled run time with the cron expression (or an Inactive badge if the schedule is paused), the associated environment and file, and when the schedule was last modified and by whom.

You can filter by environment type (KNIME, Shell, or Docker) and search by description or notes. Use the sort control to order by description or by last modified date.

Each schedule has three actions:

• Copy — duplicates the schedule with all its settings. The copy opens in edit mode so you can adjust it before saving.
• Run Now — triggers an immediate run outside of the normal cron schedule. Requires at least the Operator role. The button is disabled if the installation does not have a valid license.
• Delete — see Deleting a schedule.

Creating a schedule

Click Add Schedule, fill in the fields below, and click Save. Creating a schedule requires at least the Maintainer role — if you don't have it, the Add Schedule button is disabled. See Members & Roles for details.

Schedule

These fields apply to all schedule types.

Description — Required. A short label for this schedule, shown in the list and in run notification emails.

Notes — Optional free-text field for documentation about this schedule. Supports Markdown. A good place to record what the workflow does, who requested it, or any dependencies that are not obvious from the other settings.

Status — Controls whether the schedule fires automatically. When Active, Runner queues a run at each cron tick. When inactive, the schedule is paused — no automatic runs fire, but you can still trigger a run manually with Run Now.

Schedule — A standard five-field cron expression defining when the schedule fires. Common examples:

0 9 * * 1-5      Weekdays at 9:00 am
*/30 * * * *     Every 30 minutes
0 0 * * *        Daily at midnight
0 6 1 * *        First of the month at 6:00 am

All cron expressions are evaluated in the time zone configured in Settings.

Environment — The environment that defines the runtime for this schedule. The type of the selected environment (KNIME, Shell, or Docker) determines which additional fields appear below. See Environments for details on creating and managing environments.

Concurrency

Concurrency — Controls what happens when the schedule is triggered — by its own cron timing or by clicking Run Now — while a run of it is already active (pending, running, or canceling). Choose:

• Allow — the previous, default behavior. The new run executes in parallel with the active one.
• Skip — the new trigger is ignored. A run is still recorded with a Skipped status, so you always know it was triggered and skipped, and when.
• Queue — the new run waits until the active run finishes, then starts.
• Cancel & Replace — the active run is canceled immediately and replaced by the new one.

KNIME

These fields appear when the selected environment is a KNIME environment.

Workflow — The .knwf workflow file to execute. Select a file already uploaded to the project or upload a new one directly. Export your workflow from KNIME Analytics Platform via File → Export KNIME Workflow…; make sure all nodes are connected and reset before exporting. Files written to the /nodepit directory during execution are collected into the run's artifact archive.

Workflow Variables — Values to inject into the workflow as flow variables. Each entry requires a name, a type (String, int, or double), and a value. Variables defined here override any flow variables already set inside the workflow.

Credentials — Workflow credentials to make available during execution. Each entry requires a name, a login, and a password. These override credentials defined inside the workflow.

Reset Workflow Before Execution — When enabled, Runner resets all nodes before executing the workflow. This ensures all nodes execute from scratch and is the recommended setting for scheduled runs.

Shell

These fields appear when the selected environment is a Shell environment.

Shell Script — The .sh script file to execute. Select a file already uploaded to the project or upload a new one directly. Files written to /nodepit during execution appear in the run's artifact archive.

Environment Variables — Values made available to the script as environment variables when it runs. Each entry requires a name and a value.

Docker

These fields appear when the selected environment is a Docker environment.

Command — Overrides the image's entrypoint or default command. Leave empty to run the image's own default command. This field accepts a full multi-line script, not just a single line — paste in an entire script you already have, exactly as it exists in a file, rather than reducing it to a one-liner. Useful for retry loops or other logic that doesn't warrant its own file. For example, retrying a request a few times before giving up, using whichever runtime the image already provides — an Alpine-based image with wget, or a python/node image:

Bash

for i in $(seq 1 3); do
  wget -q --spider https://example.com && echo "Success on attempt $i" && exit 0
  echo "Attempt $i failed"
  sleep 5
done
exit 1

Python

python3 -c "
import urllib.request

for attempt in range(1, 4):
    try:
        urllib.request.urlopen('https://example.com', timeout=10)
        print(f'Success on attempt {attempt}')
        break
    except Exception as e:
        print(f'Attempt {attempt} failed: {e}')
"

Node.js

node -e "
const https = require('https');

function attempt(n) {
  https.get('https://example.com', res => {
    console.log(\`Success on attempt \${n}: \${res.statusCode}\`);
  }).on('error', () => {
    console.log(\`Attempt \${n} failed\`);
    if (n < 3) setTimeout(() => attempt(n + 1), 5000);
  });
}

attempt(1);
"

Or piping between tools, for example backing up a database straight to S3:

pg_dump -h $DB_HOST -U $DB_USER $DB_NAME | gzip | aws s3 cp - s3://backups/db-$(date +%F).sql.gz

If the command needs a tool the base image doesn't already include, install it via the environment's Additional Dockerfile Instructions — see Environments.

Prefer keeping the script as its own file — for version control, or to reuse it across schedules — rather than pasting it into this field? Upload it as an Additional File below instead, and set Command to just call it, for example python3 /nodepit/report.py.

Environment Variables — Values made available inside the container as environment variables when it runs. Each entry requires a name and a value.

Timeouts

Remove Runs After — How long to retain runs created by this schedule before deleting them automatically. Options: never, immediately, 1 hour, 1 day, 1 week, 30 days, 1 year. Cleanup runs every 60 seconds. Set to Never to retain all runs indefinitely.

Cancel Running Runs After — If a run stays in the running state longer than this threshold, Runner cancels it automatically. Options: 15 minutes, 1 hour, 6 hours, 1 day. Leave unset to fall back to the global default from Settings. Use this to tighten or loosen the global timeout for a specific schedule.

Notifications

These toggles control which run outcomes send an email notification to you personally.

Notify on successful runs — Send an email when a run completes with a passed status.

Notify on failed runs — Send an email when a run completes with a failed status.

Notify on canceled runs — Send an email when a run is canceled.

Notifications require SMTP to be configured in Settings. If SMTP is not set up, the toggles are disabled and a warning is shown. See Notifications for details on setting up email and how notification emails are formatted.

Advanced

Additional Files — Extra files mounted inside the container at /nodepit/<filename> for this schedule only. Use this for files that are specific to this schedule, such as a particular configuration or input file. Files that multiple schedules share belong in the environment's Additional Files instead.

Executor Tags — Tags that constrain which executors can handle runs of this schedule. Schedule tags are combined with any tags set on the environment — together they determine which executors are eligible. See Executors for how tag matching works.

Editing a schedule

All fields can be edited after the schedule is saved. There are no locked fields.

If your role does not permit editing (Operator or Reader), the form is shown in read-only mode.

Changes take effect immediately: the next automatic run and any manual run triggered after saving will use the updated settings.

Deleting a schedule

Deleting a schedule requires at least the Maintainer role.

A schedule cannot be deleted while it has runs in an active state (pending, running, or canceling). Wait for those runs to complete or abort them first, then retry. When a schedule is deleted, all of its associated runs are deleted as well.