Jobs

Introduction

The jobs section allows defining scheduled or event-driven tasks that execute commands or make HTTP requests. Jobs can be useful for running periodic maintenance tasks, executing background processes, or ensuring essential workflows are automated.

Job Structure

Each job consists of the following fields:

name (str, required) – A unique name for the job.
trigger (str, required) – Defines when the job should run.
- Use a duration such as 15m, 1h, or 1h30m for simple interval schedules. Supported units are s, m, h and d.
- Use a five-field cron expression, such as '*/15 * * * *' for every 15 minutes.
- Use pre-deployment to run before a new app version is created.
- Use post-deployment to run after a new app version is created.
action (required) – Specifies the task to run. More details in the next section. A job must set exactly one of:
- execute to run a command.
- fetch to make an HTTP request.
retries (int, Optional) – The maximum number of times the job should retry upon failure. Defaults to 0.
timeout (duration, Optional) – The maximum time a job is allowed to run before timing out (e.g., '10m' for 10 minutes). Defaults to 180s.
max_schedule_drift (duration, Optional) – If a scheduled run cannot start within this time of when it was due, it is skipped and the job waits for its next run (e.g., '10m' for 10 minutes). Defaults to 180s.

retries, timeout and max_schedule_drift are set on the job itself, next to trigger and action, not inside execute or fetch.

Fully working examples configuration can be found here.

Schedules and Deployment Triggers

Scheduled jobs can use either a duration or a cron expression. Schedules do not need to be uniform: an expression such as 0 9 * * MON-FRI is valid. The only requirement is that consecutive runs are at least the platform minimum interval apart, which defaults to 1 minute.

Deployment jobs use the special pre-deployment and post-deployment triggers and run once during deployment instead of being installed as recurring cron jobs.

Job Actions

This section defines the action field in a job definition. There are two types of actions for a job:

Executing a command (execute)

Runs a CLI command with Optional environment variables.
```
action:
  execute:
    command: install-wp
    cli_args:
      - "--version"
      - "--help"
    env:
      LOG_LEVEL: DEBUG
      EXTRA_FLAGS: "--enable-feature-1 --enable-feature-2"
```
- command (str, Optional) – The command to execute. If omitted, the app workload command is used.
- package (str, Optional) – Package source override for this job.
- cli_args (List[str], Optional) – Arguments for the command.
- env (map[str, str], Optional) – Environment variables.
Making an HTTP request (fetch)

Sends an HTTP request to a specific endpoint.
```
action:
  fetch:
    path: /wp-cron.php
    timeout: '10m'
    headers:
      - name: Accept
        value: application/json
      - name: User-Agent
        value: Wasmer-CronJob
    expect:
      status_codes: [200, 204]
```
- path (str, required) – The request URL path.
- method (str, Optional) – HTTP method. Defaults to GET.
- headers (List[Header], Optional) – HTTP headers passed as a list of name/value pairs.
- body (str, Optional) – Request body.
- timeout (duration, Optional) – Maximum time to wait for a response. Only used when the job-level timeout is not set; otherwise the job-level timeout applies.
- expect.status_codes (List[int], Optional) – Expected HTTP status codes.
- expect.body_includes (str, Optional) – Text that must be present in the response body.
- expect.body_regex (str, Optional) – Regular expression that must match the response body.

Example Jobs Configuration

Below are examples of various job types based on their trigger and action.

Fetch job

This job fetches the / path on its app every 15 minutes.


kind: wasmer.io/App.v0
package: wasmer/static-web-server
jobs:
  - name: ping-server-every-15-minutes
    trigger: '*/15 * * * *'
    action:
      fetch:
        path: /
        timeout: 30s
        headers:
          - name: User-Agent
            value: Wasmer-CronJob

Interval job

This job runs on a simple duration schedule.


kind: wasmer.io/App.v0
package: wasmer/static-web-server
jobs:
  - name: ping-server-every-hour
    trigger: 1h
    action:
      fetch:
        path: /
        timeout: 30s

Execute job

This job runs a shell command every 15 minutes and writes the output to the job logs. Use execute when a cron job should run a package command instead of making an HTTP request.


kind: wasmer.io/App.v0
package: wasmer/bash
jobs:
  - name: write-heartbeat
    trigger: '*/15 * * * *'
    retries: 2
    max_schedule_drift: 5m
    action:
      execute:
        command: bash
        cli_args: ["-lc", "date -u && echo cron heartbeat"]

Pre deployment job

This job runs a setup command before a new app version is created.


kind: wasmer.io/App.v0
package: wasmer/static-web-server
jobs:
  - name: prepare-release
    trigger: pre-deployment
    timeout: 5m
    action:
      execute:
        package: wasmer/bash
        command: bash
        cli_args: ["-lc", "echo preparing release"]

Post deployment job

This job fetches the / path on its app after each deployment.


kind: wasmer.io/App.v0
package: wasmer/static-web-server
jobs:
  - name: warm-up-app
    trigger: post-deployment
    action:
      fetch:
        path: /
        timeout: 30s

Use Cases

Pre-deployment migrations: The prepare-release job runs setup or migration commands before publishing the new version.
Post-deployment setup: The warm-up-app job requests the app after each deployment.
Scheduled background tasks: The ping-server-every-15-minutes job fetches the app every 15 minutes.