Scheduling from the Terminal UI

If you would rather fill in a form than write YAML, the CLI's interactive
terminal UI builds jobs.yaml for you — and it gets the command argv list
right by construction, which is the part people most often get wrong by hand.

regscale gui        # or: regscale tui

Both open the same interface. (regscale-gui and regscale-tui are installed
as standalone commands too.) The TUI is beta, like the scheduling feature
itself.

• Schedule a command
• The Schedule Job dialog
• The Jobs tab
• Run Now
• Exporting the YAML
• What the TUI cannot do

Schedule a command

1. Find the command in the command tree and open its form.
2. Fill in its parameters the way you would to run it.
3. Press Schedule… instead of running it.

The form validates first — the same required-parameter check as running it — so
you cannot schedule a command that is missing a required option. The exact argv
built from your form values becomes the job's command, so what gets scheduled
is what the form would have run.

A form with a password-type field filled in cannot be scheduled. You get
"remove the inline secret value … and configure it in init.yaml instead". This
is the same no-secrets rule the YAML path enforces, applied one step earlier:
jobs.yaml is persisted to disk, so a secret typed into the form must not reach
it. Clear the field, put the credential in init.yaml, and schedule again.

The Schedule Job dialog

Under the fields is a live preview of the next three fire times as you type:

Next: Mon 2026-09-21 02:00  ·  Mon 2026-09-28 02:00  ·  Mon 2026-10-05 02:00

That line is the whole reason to use the dialog for an unfamiliar expression —
you see what the schedule means before saving. It shows Invalid cron expression or Unknown timezone instead when a field is not usable yet.

Save validates against the same rules as the file and reports the first bad
field inline (Invalid timeout_minutes: …) rather than saving something broken.
Escape or Cancel discards.

On success the job is appended to your jobs.yaml and you get
Scheduled '<name>' — see the Jobs tab. If that name is already taken, the new
job is saved as <name>-2, <name>-3, and so on, and the notification names
the one that was actually used — worth reading, because it means you now have
two similar jobs.

The Jobs tab

Ctrl+J, or the Jobs tab. It lists every job in your jobs.yaml:

Selecting a row fills the Run History table below it with that job's last 20
runs — started time (UTC), trigger, state, exit code, duration.

The status line at the top of the tab tells you whether a scheduler is alive:

Scheduler last tick: 2026-09-16T14:32:07+00:00

or, when nothing has run a pass recently:

Scheduler: no recent activity (start 'regscale jobs daemon' or cron 'regscale jobs run-due')

That second message is the one to internalize: the TUI schedules jobs, it does
not run them. Nothing fires until a daemon or a run-due trigger exists — see
Deployment.

Toolbar actions, all operating on the selected row:

Use Refresh after editing the file in an editor, and Disable rather than
Delete when you only want a job to stop for now. If the file on disk is
invalid, the tab says so on the status line instead of showing a stale list.

Run Now

Run Now runs the selected job the same way the scheduler would — it is not a
different code path:

• Output streams live into the Console tab as it happens.
• The run is recorded in run history with trigger=tui, so it shows up in both
  this tab and regscale jobs history <name>.
• Notification email fires on the outcome, exactly as for a scheduled run.
• The job's timeout_minutes applies.

It does not change what the scheduler thinks is due, so a job you run by
hand at 10:00 still runs on its normal 02:00 schedule. Only one Run Now at a
time, and not while the Console runner is busy — you get a warning and are
shown the live console instead.

Exporting the YAML

Export YAML puts the whole jobs.yaml, as the CLI would write it, on your
clipboard. Use it to:

• Paste a config you built interactively into a git repository or an Azure Blob
  for remote hosting.
• Copy a working set of jobs to another host or into a container image.
• Review exactly what the TUI wrote, including the defaults it filled in.

Build the schedule locally in the TUI, export, paste into the blob your
containers read — that is the intended loop, and it keeps hand-written YAML out
of the process entirely.

What the TUI cannot do

• It edits only the local jobs.yaml — the default path, or
  REGSCALE_JOBS_FILE if you have set it. A config served from
  --config-url is read-only from the TUI's point of view; edit locally and
  re-upload the export.
• It is not a scheduler. Closing the TUI stops nothing and starts nothing.
• It cannot rename a job. Names are the key for state and history, so
  editing locks the name. To rename, create the job again under the new name and
  delete the old one, accepting that history does not follow.
• It cannot set on_success recipients or a description, and it will not
  discard ones already in the file — the dialog preserves what it does not show.
  Edit jobs.yaml directly for those.