Skip to content

Scheduled tasks

The Settings → Scheduled tasks tab.

Scheduled tasks automatically run recurring operations on the platform.

Task types

  • Application tasks: target an application within a namespace — restart, start, stop an application, take a snapshot with retention, queue a Hop job…
  • System tasks: platform maintenance (database cleanup, application reconciliation…), restricted to administrators.

Creating a task

New task → name, description, task to run (chosen from the catalog), target (application/namespace for an application task), and schedule:

  • Interval: every n seconds/minutes/hours/days, with an optional Start time: the task does not run before that date. It is entered in your browser's time (the timezone is shown next to the field, "Time zone: …") and stored in UTC. If left empty, the first run happens one interval after saving, and the list shows that date ("from …");
  • Cron: minute, hour, day of month, month, day of week, with a Timezone picked from a searchable list (your browser's by default); with none, it is UTC.

A task can be disabled without being deleted, and run now (dedicated button) regardless of its schedule.

Creating or editing an application task requires the admin role on the target application's namespace.

Application tasks

An application task targets a specific application — except Stop all applications in a namespace, which targets a whole namespace directly (the application field is then hidden in favor of a namespace field).

The target application's name and namespace are always derived from the selected application: never enter them as keyword arguments.

Restart / Start / Stop application

Nothing to enter: just pick the application.

For Start application only, the replica count can be set in Advanced options → Keyword arguments (defaults to 1):

{ "replicas": 2 }

Warning

Do not add release_name to the keyword arguments: it is already passed automatically, and the duplicate makes the run fail.

Stop all applications in a namespace

No task/application to pick in the main form: a dedicated Namespace field appears instead of the Application field. No keyword arguments to enter — {"namespace": "..."} is injected automatically from that field.

Application snapshot (with retention)

Simplified form (visible without "Advanced options"): a single field, Number of snapshots to keep (integer ≥ 1, defaults to 7). release_name/namespace are derived automatically from the selected application — do not enter them as keyword arguments.

Example: automatic volume snapshot

A daily snapshot of a critical application's volume: cron schedule 0 2 * * *, retention of 7 snapshots. To restore a snapshot created this way, see Volumes.

Call REST API

{
  "url": "https://example.com/api/hook",
  "method": "POST",
  "json_body": { "key": "value" },
  "headers": { "X-Custom": "value" },
  "auth_param": "namespace_parameter_name",
  "timeout": 30
}
  • url (required).
  • method: GET, POST… (defaults to POST).
  • json_body: JSON body sent as-is (optional).
  • headers: additional HTTP headers (optional).
  • auth_param: the name of a parameter on the selected application's namespace — its value is read and injected as-is into the Authorization header (e.g. Bearer xxx). This is the parameter's name, not the token itself. The namespace is enforced by the selected application: a namespace entered in the arguments is ignored.
  • timeout: seconds (defaults to 30).

Enqueue Hop job

{
  "queue_name": "my-hopqueue",
  "kind": "pipeline",
  "path": "/files/projects/current/mypipeline.hpl",
  "name": "MyPipeline",
  "parameters": {},
  "run_config": "local"
}
  • queue_name: the name of an existing HopQueue on the Hop Server application (not to be confused with the Queue field described below — a Celery queue, a distinct concept).
  • kind: pipeline or workflow.
  • path: the .hpl/.hwf file path, as returned by the Hop Server application's file list (prefixed with /files/projects/current/).
  • name: the pipeline/workflow's internal name (the Hop file's name attribute — not the scheduled task's own name entered at the top of the form).
  • parameters: pipeline/workflow parameters (object, optional).
  • run_config: Hop run configuration (e.g. local) — in practice required, execution fails on the Hop Server side without it.

Note

This entry remains a low-level access path. To schedule actual recurring Hop jobs, the dedicated Scheduled recurring jobs section of the Hop Server application itself (guided form, per-job history) is the recommended route — see Apache Hop Server: jobs and scheduling.

Advanced options

The Advanced options button on the form reveals fields normally hidden:

  • Keyword arguments: the task's parameters as free-form JSON — see the per-task detail above. Application snapshot and Stop all applications in a namespace have their own simplified form and don't need it.
  • Queue: the Celery queue that runs the task (advanced setting, rarely needed — unrelated to a HopQueue).
  • Positional arguments: the positional-list equivalent of keyword arguments, for one-off needs.

Monitoring

Each task shows its last run and its total run count; its history lists past runs with their status and result, filterable by status.