tokio-cron-scheduler vs apalis

The short answer

• Reach for tokio-cron-scheduler when you want to run a function on a schedule inside your async service and it’s fine to occasionally lose a run on restart. Cache refreshes, heartbeats, digest emails, periodic syncs.
• Reach for apalis when each scheduled run is a durable unit of work — it must survive crashes, retry on failure, and maybe spread across workers. Billing, payouts, report generation, anything you can’t silently drop.

Everything else below is the reasoning behind that split.

Different tools, not rivals

The comparison is a little unfair because they sit in different categories:

• tokio-cron-scheduler is a scheduler. Its whole job is “call this closure when the clock matches.” It holds schedules in memory, runs them on your Tokio runtime, and offers cron, fixed-interval, and one-shot jobs.
• apalis is a background-job framework — the same family as Sidekiq (Ruby) or Celery (Python). Jobs come from a backend and are consumed by workers, with Tower middleware for retries, timeouts, concurrency, and tracing. apalis-cron is simply one backend that emits a job every time a cron schedule fires.

So the honest framing isn’t “which scheduler is better.” It’s: do you need scheduling, or do you need durable job processing that happens to be time-triggered? That single question decides it, and everything else is detail.

Cron format differences

If you take one practical thing from this page, make it this — the two crates parse different cron dialects, and pasting one into the other silently misfires:

Both support a seconds field, so both can do sub-minute schedules the Unix format can’t. The gotcha is purely the field count — apalis’s trailing year. Run either through the cron parser if you’re unsure.

Durability and retries

This is the real decision axis, and it’s where the most common misconception lives: apalis is not automatically more crash-safe.

• tokio-cron-scheduler keeps schedules in memory. A restart forgets them until your code re-adds them on boot — fine for code-defined jobs, a problem for dynamic ones. The optional postgres_storage / nats_storage features persist the schedule definitions, not a durable record of each individual run. Retries and overlap handling are yours to implement.
• apalis-cron’s CronStream also fires in memory — the trigger itself is no more durable than tokio-cron-scheduler’s. apalis earns its reliability only when you route the emitted jobs through a storage backend — apalis-redis or apalis-sql (PostgreSQL/MySQL/SQLite). Then each firing becomes a persisted job with at-least-once delivery, and retries come for free through Tower middleware (RetryPolicy), alongside timeouts, concurrency limits, and tracing.

So the durability question is really: are you willing to run Redis or a SQL queue? If yes and the work is important, apalis’s per-run durability and built-in retries are worth the weight. If no, tokio-cron-scheduler is the lighter, infra-free choice — and you accept that a crash mid-run loses that run.

The same job in both

An hourly job, written each way. First tokio-cron-scheduler — the scheduler owns the loop:

use tokio_cron_scheduler::{Job, JobScheduler};

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let sched = JobScheduler::new().await?;

    // 6-field: sec min hour dom month dow
    sched.add(Job::new_async("0 0 * * * *", |_uuid, _lock| {
        Box::pin(async move { hourly_task().await; })
    })?).await?;

    sched.start().await?;
    tokio::signal::ctrl_c().await?;
    sched.shutdown().await?;
    Ok(())
}

Now apalis-cron — a worker consuming a cron-driven backend, with a retry layer:

use apalis::{prelude::*, layers::retry::RetryPolicy};
use apalis_cron::{CronStream, Schedule};
use chrono::Local;
use std::str::FromStr;

#[derive(Default, Debug, Clone)]
struct Tick;

async fn hourly_task(_job: Tick, _ctx: CronContext<Local>) {
    // ... the work ...
}

#[tokio::main]
async fn main() {
    // 7-field: note the trailing year
    let schedule = Schedule::from_str("0 0 * * * * *").unwrap();

    let worker = WorkerBuilder::new("hourly")
        .retry(RetryPolicy::retries(3))          // built-in, not hand-rolled
        .backend(CronStream::new(schedule))
        .build_fn(hourly_task);

    worker.run().await;
}

The apalis version is more ceremony for the same trigger — the payoff is the middleware stack and, once you add a storage backend, durable per-run processing. For a truly durable setup you’d route jobs through apalis-redis/apalis-sql; see the apalis guide.

Using them together

They aren’t mutually exclusive — the strongest setup often uses both. Let tokio-cron-scheduler be the trigger and have its closure enqueue an apalis job:

// tokio-cron-scheduler fires on time…
sched.add(Job::new_async("0 0 * * * *", move |_uuid, _lock| {
    let mut storage = storage.clone();     // apalis-redis / apalis-sql
    Box::pin(async move {
        // …and hands a durable job to apalis for reliable processing.
        storage.push(GenerateReport { /* … */ }).await.ok();
    })
})?).await?;

This splits the two concerns cleanly: tokio-cron-scheduler answers “when should this run?” with a lightweight in-process timer, and apalis answers “reliably do the work, with retries and observability.” You skip apalis-cron entirely and get the best of each — simple scheduling plus durable execution.

Which to choose

Decision rule: if losing an occasional run on restart is acceptable, use tokio-cron-scheduler — it’s lighter, needs no infrastructure, and covers most periodic work. If a missed or failed run is a real problem, use apalis with a storage backend for durability and retries. And when you want both simple scheduling and durable processing, compose them: tokio-cron-scheduler to trigger, apalis to execute.

For the full landscape of Rust scheduling crates — including the cron crate for parsing and clokwerk for interval DSLs — see the Rust cron scheduling guide.