Skip to main content
Cron jobs run shell commands on a schedule, in UTC, inside a service’s container image. Declare them in floo.app.toml; every deploy syncs them.

Declare in config

Add [cron.<name>] sections to floo.app.toml:

Fields

Deploy and verify

Push to GitHub or run floo redeploy. Each deploy creates new jobs, updates changed ones, and deletes removed ones. Dev and prod each have their own copy of every job, and both run on schedule with their own environment’s env vars and managed services. A push syncs the dev jobs; a prod release syncs the prod jobs. floo cron list, show, and run default to dev; pass --env prod for prod.
Then verify:

Manually trigger a job

Common schedule expressions

How it works

  1. You declare [cron.<name>] in floo.app.toml
  2. A deploy reads the [cron.*] sections from floo.app.toml in the deployed commit
  3. floo creates, updates, or deletes cron job records to match the declarations
  4. Jobs run inside the specified service’s container image with the same environment variables
A job sees the same DATABASE_URL, REDIS_URL, and other env vars as the service it runs in.

Failure handling

Cron jobs do not retry. Each scheduled run executes once; if the command exits non-zero or exceeds its timeout, that run is marked failed. The next scheduled run is the only recovery; there is no backoff. Where a miss matters, make the command idempotent, handle retries inside it, and alert on failure: floo logs query --app my-app --cron <job> --env prod shows the cron output with [cron:<job>] attribution, and agent webhooks can route repeated failures to your agent or on-call.

JSON output

CLI reference

See the exact floo cron list and floo cron run flags, JSON shape, and --preflight behavior.