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 runfloo 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.
Manually trigger a job
Common schedule expressions
How it works
- You declare
[cron.<name>]infloo.app.toml - A deploy reads the
[cron.*]sections fromfloo.app.tomlin the deployed commit - floo creates, updates, or deletes cron job records to match the declarations
- Jobs run inside the specified service’s container image with the same environment variables
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 itstimeout, 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.