Schedulers

A schedule is a saved prompt plus a trigger. Slo runs it later without anyone at the keyboard: a morning test report, a check on the repo every hour, an audit next Tuesday.

Slo doesn't run its own background service for this. It uses the scheduler your operating system already has:

  • macOS: launchd
  • Linux: cron

When a schedule is due, the OS runs slo schedule execute --name <schedule>. Slo loads the schedule, does the work once, writes a record of what happened, and exits.

slo schedule list and reports.

Quick start

Create a schedule:

slo schedule add \
  --name "Daily summary" \
  --prompt "Summarise today's changes and any failing tests." \
  --cron "0 18 * * *" \
  --cwd ~/code/payments \
  --session-mode fresh

Register it with your OS so it actually runs:

slo schedule install --name "Daily summary"

At 18:00 every day it runs as a headless slo run and saves a record. Check the records with:

slo schedule reports --name "Daily summary"

Fresh or continuous

The session mode decides whether runs build on each other:

ModeEach run...Good for
freshstarts a brand-new sessionDaily summaries, one-off checks
continuouscontinues one named sessionWatching a repo over time, release prep, checking on a long workflow

Triggers

Each schedule has exactly one:

FlagMeaning
--cron "0 18 * * *"A standard five-field cron expression.
--interval-seconds 300Every N seconds.
--run-at "2026-10-20T09:00:00+00:00"Once, at that time.

Add --tz for the time zone of a cron trigger (default UTC), and --model or --cwd to choose the model and folder.

All the commands

CommandWhat it does
addCreate a schedule.
editChange one, keeping its id.
listEvery schedule with its mode, trigger, target session, whether it's installed, and its last run.
showOne schedule.
execute (or run)Run it now. This is what the OS calls.
install / uninstallRegister it with the OS, or remove it.
reportsPast runs of a schedule.
show-reportOne past run in detail.
cleanupDelete old run records, keeping the newest --keep (default 100).

More examples

A one-off audit

slo schedule add \
  --name "Release audit" \
  --prompt "Audit the release branch and list anything that would block deployment." \
  --run-at "2026-10-20T09:00:00+00:00" \
  --session-mode fresh

slo schedule execute --name "Release audit"

Watching a repo without flooding yourself

For frequent checks, point every run at one session and keep only the newest pending check:

slo schedule add \
  --name "Repo watch" \
  --prompt "Check the repo and summarise new failures, flaky tests and regressions." \
  --cron "*/5 * * * *" \
  --cwd ~/code/payments \
  --session-mode continuous \
  --session-reference repo-watch \
  --coalescing-mode latest_by_key \
  --coalescing-key repo-watch

latest_by_key means a newer check replaces an older one that hasn't run yet. Come back after an hour away and you'll find one waiting, not twelve. The run record shows it as coalesced.

Looking after your records

slo schedule list
slo schedule reports --name "Repo watch"
slo schedule show-report --name "Repo watch" --run-id 6d9a7e5b-...
slo schedule cleanup --name "Repo watch" --keep 25

Running into a session you have open

This is the part that keeps things safe. If a continuous schedule targets a session that's open in a TUI right now, starting a second process on the same session would mean two writers on one conversation.

So Slo doesn't. Instead:

  1. The scheduled prompt goes into that session's inbox.
  2. The TUI picks it up when it's idle, and runs it as a normal turn.
  3. If the session isn't open anywhere, Slo resumes it in the background instead.

Scheduled work can feed a live session without ever tripping over you.

How it fits together

slo schedule add        saves the prompt and trigger under ~/.slo/schedules/
slo schedule install    registers it with launchd or cron
the OS scheduler        runs: slo schedule execute --name <schedule>
Slo                     does the work once and writes one run record

On macOS each schedule becomes a file in ~/Library/LaunchAgents/. On Linux each gets a marked block in your crontab. Logs go to ~/.slo/schedules/logs/, and the run records under runs/ are the source of truth.

Checking in on a dynamic workflow

A scheduled run doesn't start sub-agents itself. But it can check on a dynamic workflow that's already going, by sending a prompt into the orchestrator's session every hour:

A scheduled run waking an orchestrator to check on its sub-agents.

slo schedule add \
  --name "Nightly review check-in" \
  --prompt "Check the running sub-agents. Report which phases are still going,
            retry anything stalled, and summarise what's finished." \
  --cron "0 * * * *" \
  --session-mode continuous \
  --session-reference nightly-review \
  --coalescing-mode latest_by_key \
  --coalescing-key nightly-review

slo schedule install --name "Nightly review check-in"

Watch it any time with slo visualize --session nightly-review --follow. More recipes in Put Slo on autopilot.