Scheduled jobs and background tasks
Running work outside a request: background tasks, timers, and scheduled jobs — their limits, where to see them, and when they run.
A Floot backend has no always-on process. Work that should not hold up a request, or should happen later, or should repeat on a schedule, runs as a job instead. There are three kinds, and your assistant picks the right one when you describe what you want.
| Kind | What it does | Example | Plan |
|---|---|---|---|
| Background task | Runs now, outside the request that started it. One task can start many more. | Process an upload; build a report for each of 500 customers | Every plan |
| Timer | Runs once, at a time between 1 minute and 7 days from now. | Send a reminder an hour before a booking; expire an invite after 24 hours | Paid |
| Scheduled job | Runs on a repeating schedule, in the time zone you choose. | Email a digest every morning at 8 | Paid |
"Paid" means the project owner is on a paid plan. A collaborator's own plan does not count.
Setting one up
Ask your assistant. There is no create button; jobs are part of your app's code.
Every weekday at 9am New York time, email me a summary of yesterday's orders.When a booking is made, send the customer a reminder one hour before it starts.Where to see them
Open your project on floot.com and go to Services → Schedules. Each scheduled job is listed with its schedule, an on/off switch, Run now, and Delete task. Run now runs the job once, straight away, with the project's current code — the way to test a job without waiting for its time. It works on your real data: the preview and the published app share one database.
Timers and repeating tasks that your app created while running are listed below them, under Background tasks, where you can cancel any of them.
When scheduled jobs run
- In the published app. A job you have just added does nothing until you publish.
- While the project owner is on a paid plan. On a free plan the job is saved and listed, but it does not run.
- With the code and schedule of your last publish. Editing a job, changing its time, or switching it off in the panel changes nothing in the published app until you publish again. To stop a job that is running in the published app, switch it off and then publish.
- One run at a time. If a job's previous run is still going, including the tasks that run started, the next one is skipped rather than stacked on top.
- Not while hosting is paused. If your hosting balance goes negative, scheduled jobs and repeating tasks in your published apps pause until it is paid — see Hosting.
Timers follow the app they were set in. One set by your published app fires in the published app. One set while you test in the preview fires only if the preview was open in the 15 minutes before it is due.
Limits
| Limit | Value |
|---|---|
| Scheduled jobs per project | 10 |
| Shortest schedule | Every 5 minutes |
| Timers waiting at once | 25 per project, each 1 minute to 7 days out |
| Repeating tasks your app creates while running | 10 per project, every 5 minutes at most |
| Longest single run | 15 minutes |
| Data passed to a task | 100 KB |
A run that reaches 15 minutes is stopped and is not started again. For longer work, ask your assistant to split it into steps: each step saves its place in the database and queues the next one.
What a background task guarantees
A background task starts right away and has nobody waiting on it, so a failure is silent unless your app records it. A task that fails or is cut off partway is not run again. Have the task write its progress and its result to your database, and make it safe to run twice, so that a retry from your own code does no harm. Your assistant knows these patterns — tell it the work must not be lost.
What they cost
Jobs are metered as ordinary hosting usage: the time your backend runs. The less obvious cost is the database. Every run that reads the database wakes it, and it then stays awake for a while, so a job that checks every few minutes whether there is anything to do keeps the database running much of the day, even when the answer is always no. The Schedules panel shows an estimate next to any job that runs that often.
The fix is usually a timer instead of a frequent job: when the deadline is created, set a timer for the moment the work is due, and nothing runs in between. Ask your assistant to make that change.