Task scheduling
Schedule background work in Dart without cron: future calls run your code later, survive restarts, and are queued in your database, so no jobs are lost.
Future calls
Every backend eventually needs work that runs later: a reminder 24 hours after an order, a cleanup at midnight, a retry in five minutes. Cron jobs and job queues can do it, but they live outside your application, are awkward to test, and add another moving part to your system.
Serverpod's future calls are plain Dart functions scheduled with a delay or run at a specific time. They are persisted in your database and executed by the server, so they survive restarts and can run across your server cluster without an external scheduler.
How it works
1Define it
Extend FutureCall and add the method you want to run later. It takes a Session and any typed payload.
class ReminderFutureCall extends FutureCall {
Future<void> send(Session session, Order order) async {
// Send the reminder for this order.
}
}
2Run serverpod start
serverpod start regenerates the type-safe interface for your future calls as you save, and the running server registers them on start.
serverpod start
3Schedule it
Queue the call to run after a delay or at a specific time, passing the payload it needs.
await session.serverpod.futureCalls
.callWithDelay(const Duration(hours: 24))
.reminder
.send(order);
Flexible scheduling
Schedule work a fixed duration from now, at a specific timestamp, or on a recurring schedule from a cron expression or a fixed interval.
await session.serverpod.futureCalls
.callRecurring(identifier: 'daily-reminder')
.cron('0 8 * * *')
.reminder
.send(order);
Survives restarts
Scheduled calls are stored in your database, so a deploy or a crash does not drop pending work; the server picks it back up.
Distributed execution
Future calls run across your cluster, so scheduled work scales with your servers rather than being pinned to a single machine.
Everything included
Why Serverpod
Works with
Postgres
Frequently asked questions
Does Serverpod replace cron jobs?
Yes, for application-level scheduled work. Future calls run your Dart code on a delay or at a timestamp.
Do scheduled jobs survive a restart?
Yes. Future calls are persisted in the database, so pending work is not lost on deployment or crash.
Can I run recurring jobs?
Yes. Schedule a call as recurring with a cron expression or a fixed interval, and the server runs it on that schedule.
Can I pass data to a scheduled job?
Yes. A future call takes typed arguments, including your generated models.
When should I not use this?
For very high-frequency, sub-second scheduling or heavy job pipelines, a dedicated message broker may be a better fit.