Skip to main content
floo cron is the read-only + manual-trigger surface for scheduled cron jobs. Cron jobs are declared in floo.app.toml under [cron.<name>] sections — they are not created with the CLI. Every deploy reconciles the declared set: new sections become jobs, removed sections are deleted, changed sections are updated.
Looking for how to add a cron job? Edit floo.app.toml, not the CLI. See Cron Jobs for the schema and end-to-end flow, or Config Spec → [cron.<name>] for the field reference.

list

List every cron job declared on an app along with its enabled state, last status, and last run time.

Flags

JSON output

last_run_at and last_status are null until the first run completes. last_status is success or failed — the API only writes the row after the run reaches a terminal state, so there is no in-between “running” value.

show

Show details for a single cron job by name.

Arguments

Flags

JSON output

Errors


run

Manually trigger a cron job by name. Useful for testing or one-off catch-up runs without waiting for the schedule.

Arguments

Flags

What it does

  1. Resolves the app from --app or the nearest floo.app.toml.
  2. Calls the platform’s “trigger cron job” endpoint, which dispatches a one-off Cloud Run Job execution against the service’s container image.
  3. Waits for the run to complete and returns the final outcome. The job’s last_run_at and last_status are updated before the call returns, so a follow-up floo cron list reflects the run immediately.

What the CLI does NOT do

  • Add jobs. Edit floo.app.toml. The next deploy creates the job.
  • Remove jobs. Delete the [cron.<name>] section from floo.app.toml. The next deploy deletes the job.
  • Edit schedules or commands. Change them in floo.app.toml. The next deploy updates the job.
This is intentional. Schedules are stateless reconcilable resources — keeping them config-driven means the repo is the source of truth and every change ships through the same review/deploy flow as code.