Run a command on a schedule with a scheduled job

What a scheduled job is for

A Scheduled job is an application that runs a command at set times, then stops: a nightly report, a cleanup every hour, the scheduler of your framework every minute. Between two runs it reserves nothing on your nodes. For a process that must run all the time, create a worker.

Create a scheduled job

Owners, admins and developers create one.

1. Open the project and choose Add resource.
2. Choose Scheduled job as the application type.
3. Choose its source. Choose an application source compares them. To run the code of a web application with another command, give it the same repository or image.
4. Fill Schedule.
5. Fill Entrypoint when a run must start with another command than the one its image declares, such as node ace reports:send.

Write the schedule

The schedule is a cron expression of five fields, read in UTC:

minute  hour  day of the month  month  day of the week

A field is *, a number, a range such as 1-5, a list such as 0,30, or a step such as */15. The day of the week goes from 0 for Sunday to 6 for Saturday. Names such as mon and shortcuts such as @daily are refused.

Deploy it

Choose Deploy on the page of the scheduled job, or enable its deploy hook. A deployment never starts a run: the first run comes at the next time of the schedule, or when you start one now.

A scheduled job reads its configuration from variables, and you bind it to a managed service to reach a database. Tenkai does not set PORT for it.

How a run starts

A scheduler on your cluster starts the runs, so your jobs keep running while Tenkai is down. A run executes on any node that accepts workloads.

• One run at a time. When the run before has not ended, the scheduler skips that time.
• No retry. A failed run is not started again.
• No catch-up. A time that passes while the scheduler moves to another manager node is skipped.

A run in progress on a drained node stops with it.

When Tenkai stops a run

Moving the edge node and forcing the removal of a worker node stop the runs in progress of every scheduled job of the cluster. Their confirmation says so. Neither starts a run again: each job runs at the next time of its schedule, or when you start one now.

A stopped run then shows as Outcome unknown, and the Logs tab no longer shows what the earlier runs wrote.

Follow the runs

The overview of a deployed scheduled job lists its last 20 runs, with how each one ended:

• In progress: its command has not ended. The time to pull the image counts.
• Succeeded: its command ended with the exit code 0.
• Failed: its command ended with another exit code, or the run could not start, or it was stopped. The list shows what the cluster said, such as task: non-zero exit (3).
• Outcome unknown: Tenkai could not read how it ended.

When the last run failed, the page says The last run failed. Tenkai sends no email and no notification.

A run shows up to a minute after it starts or ends. Tenkai keeps runs for 30 days. If Tenkai cannot reach the cluster for more than 5 minutes, the list may miss runs, though the cluster kept starting them. Skipped times are not listed.

Start a run now

Owners, admins and developers choose Run now above the list of the runs. The run uses the active release. Run now is disabled while a run has not ended.

Read what a run wrote

The Logs tab shows what the last runs of the active release wrote. It starts empty after a deployment or a rollback. A scheduled job has no Terminal tab.

Change the schedule, the command or the size

Open the scheduled job, then More actions and Change configuration….

• A new Schedule applies at once, without a deployment.
• A new Entrypoint or Size needs Apply configuration or a deployment.

Roll back

Roll back, in the history on the overview, makes the next runs use an earlier release, without a build. A run in progress ends with the release it started with.

Delete it

Delete removes the scheduled job from the cluster. A run in progress stops.

What a scheduled job cannot do yet

• Retry a failed run, or notify you when one fails.
• Show a time of the schedule that was skipped.
• Run two runs at the same time.
• Keep files between two runs.
• Report a runtime drift.