Schedules

Sometimes you don't need something running all the time, you need it to run once, on a timer, inside a service that's already deployed. Nightly cleanup, a periodic report posted to Discord, a cache warm-up before peak hours. Schedules cover exactly that, and they live on each service's own Schedules tab.

Setting one up

A schedule is three things:

• A name, so you can tell your schedules apart at a glance.
• A cron expression for when it runs, standard five-field cron, for example this runs at 2am every day:

0 2 * * *

• A command to run inside the service's container or process when it fires, for example:

npm run cleanup

Flow validates the cron expression when you save, so a typo gets caught immediately rather than silently never running.

Watching it run

Each schedule shows whether it's enabled, its cron expression and command, and when it last ran, or "Never run" if it hasn't fired yet. From its menu you can:

• Run now, trigger it immediately without waiting for the schedule, useful for testing a new one before you trust it to run unattended overnight.
• View runs, a history of every past run, each with its status and, when you select one, the actual output it produced, so you can go back and check what a 2am run from last week actually did.
• Enable or disable it without deleting it, handy if you need to pause something temporarily.
• Edit or Delete it.

A run moves through pending, running, and then either succeeded or failed, the same shape as a deployment's status, so it should feel familiar if you've already watched a few deploys happen.

Worth knowing

The command runs inside the same environment as the service itself, same environment variables, same network access to the rest of its project, so anything your bot or site can already reach, a schedule running inside it can reach too. And because scheduled runs happen on the node the service lives on, the service does need to actually be deployed there for its schedules to have anything to run inside.