How can I schedule recurring tasks (cron) in a serverless app without running my own worker servers?

Most teams hit the same wall with serverless: your API routes and functions are easy to deploy, but the moment you need a recurring task—daily reports, hourly syncs, cleanup jobs—you’re suddenly being told to “just add a worker.” Now you’re back to managing EC2 instances, queues, and custom cron infrastructure, which defeats the point of serverless.

This guide walks through how to schedule recurring tasks (cron) in a serverless app without running your own worker servers, and why an event-driven, durable execution platform like Inngest changes the model entirely.

---

Quick Answer: You Don’t Need Workers, You Need Durable Schedules

If you’re building on edge/serverless runtimes (Vercel, Netlify, Cloudflare Workers, AWS Lambda, etc.), the most sustainable way to schedule cron-like tasks is:

• Use an external scheduler that:
  • Triggers your code via events, not ad-hoc HTTP requests.
  • Guarantees delivery (no dropped runs).
  • Handles retries and backoff automatically.
• Run your recurring logic as durable functions:
  • Code written as normal functions in your language (TypeScript, Go, Python).
  • Each step is retried on failure and resumes from the last checkpoint.
  • No workers, queues, or cron daemons to maintain.

Inngest was built for exactly this: you declare a schedule in code, and Inngest takes care of the scheduler, infrastructure, retries, and observability.

---

Why “Just Use Cron” Breaks Down in Serverless

Classic cron assumes:

• A long-lived machine.
• A stable process that can run indefinitely.
• Your script will finish before you need to reboot or scale down.

In serverless, you get:

• Short-lived invocations with platform timeouts.
• No guarantee a given machine will exist at the next tick.
• Scaling based on inbound requests, not on a cron schedule.

Typical “solutions” people reach for:

• Cloud provider cron services (e.g., EventBridge, Cloud Scheduler, Cloudflare Cron Triggers):
  • Good at firing an HTTP request on a schedule.
  • Not good at multi-step workflows, retries, or handling partial failures.
• DIY workers with queues:
  • You roll your own:
    • worker processes
    • SQS / RabbitMQ / Kafka queues
    • retry logic
    • dead-letter queues
    • monitoring dashboards
  • You just traded “no servers” for “a homegrown job system.”

If you care about reliability—especially in multi-tenant SaaS—this DIY path becomes an infrastructure tax you’ll pay forever.

---

What You Actually Need From Scheduled Tasks

When I was running multi-tenant SaaS workloads on Lambda and Kubernetes, recurring jobs looked simple on a whiteboard but nasty in production. The real requirements were:

• Durability:
  If a run fails halfway (say, you processed 400/1,000 tenants) you shouldn’t start from scratch; you want to resume from the last successful step.
• Retry behavior that doesn’t duplicate work:
  Retries should be automatic and idempotent. You don’t want double charges, duplicate emails, or re-running heavy computations unnecessarily.
• Multi-tenant safety:
  One tenant with a large dataset shouldn’t starve everyone else. You need:
  • concurrency keys,
  • throttling, and
  • prioritization baked into the platform—not hand-rolled as infrastructure.
• Observability out of the box:
  When a nightly run fails, you want:
  • Real-time traces,
  • Structured logs,
  • Step-level inputs/outputs, and the ability to query, cancel, or replay runs without building admin tools.
• Local dev and simple deployment:
  Cron shouldn’t be the “special” part of your system that you can’t run locally or ship via your existing CI/CD.

That’s the bar. Anything that doesn’t meet it turns into more toil: dead-letter queues, log-grepping across services, bespoke replay scripts, and infra you didn’t want to own.

---

Infraless Cron: How Inngest Handles Scheduled Tasks

Inngest’s model is simple:

• You write functions using inngest.createFunction().
• You define when they should run using a schedule (cron syntax or human-readable intervals).
• Inngest handles:
  • scheduling,
  • event delivery,
  • step-level durability,
  • retries, and
  • observability.

No workers, no queue setup, no cron daemon.

1. Declare Scheduled Functions in Code

In TypeScript, a scheduled function looks like this:

import { Inngest } from "inngest";

const inngest = new Inngest({ name: "my-app" });

export const nightlyBilling = inngest.createFunction(
  { id: "nightly-billing" },
  { cron: "0 2 * * *" }, // Every day at 02:00 UTC
  async ({ step }) => {
    const tenants = await step.run("fetch-tenants", async () => {
      // Fetch tenant list from your DB
    });

    await step.run("bill-tenants", async () => {
      // Bill each tenant, enqueue downstream events, etc.
    });
  }
);

Mechanism → outcome:

• Mechanism: cron: "0 2 * * *" is declared alongside the function.
• Outcome: Inngest reliably kicks off this function every night at 02:00 UTC, even though you’re not running any worker servers.

2. Durable Steps With step.run()

Each step.run() acts as a code-level transaction:

await step.run("bill-tenants", async () => {
  // If this throws, Inngest retries with backoff.
  // On success, it never runs this step again,
  // even if the whole function is retried later.
});

What this buys you:

• Automatic retries on failure.
• Once-and-only-once behavior on success.
• Checkpointing: if a later step fails, you resume from the last successful step instead of restarting the whole function.

This is exactly what you want on scheduled jobs that might:

• hit external APIs with rate limits or intermittent failures,
• process large batches of tenants or records, or
• call AI models multiple times in a workflow.

3. Infraless by Design

You don’t run workers or schedulers:

• No Kubernetes cronjobs.
• No EC2 worker pool.
• No SQS / Redis / RabbitMQ to glue together.

Your cron-like tasks are just Inngest functions deployed alongside your existing stack:

• Edge (Vercel Functions, Cloudflare Workers),
• Serverless (AWS Lambda, Netlify, etc.), or
• Traditional servers (Node, Python, Go on ECS/Kubernetes).

Inngest’s infrastructure does the queueing, scaling, concurrency, throttling, and rate limiting for you.

---

Example: Hourly Sync Without Workers

Say you need to sync data with a third-party API every hour for each active tenant. You want:

• An hourly schedule,
• Safe per-tenant concurrency,
• Backoff on API rate limits,
• Visibility when a tenant’s sync fails.

Here’s how that might look:

export const hourlySync = inngest.createFunction(
  { id: "hourly-tenant-sync" },
  { cron: "0 * * * *" }, // every hour
  async ({ step }) => {
    const tenants = await step.run("fetch-active-tenants", async () => {
      // SELECT id FROM tenants WHERE active = true
    });

    // Process tenants in batches to avoid noisy neighbors
    await step.run("sync-tenants", async () => {
      for (const tenant of tenants) {
        await inngest.send({
          name: "tenant.sync.requested",
          data: { tenantId: tenant.id },
        });
      }
    });
  }
);

// Separate function, concurrency-bound per tenant
export const syncTenant = inngest.createFunction(
  {
    id: "sync-tenant",
    concurrency: "tenantId", // one run per tenant at a time
  },
  { event: "tenant.sync.requested" },
  async ({ event, step }) => {
    const { tenantId } = event.data;

    const data = await step.run("fetch-remote-data", async () => {
      // Call third-party API
    });

    await step.run("update-local-state", async () => {
      // Write updates to DB
    });
  }
);

Mechanisms:

• cron expression triggers the hourly fan-out.
• ingest.send emits a per-tenant sync event.
• concurrency: "tenantId" ensures one sync per tenant at a time.
• step.run() isolates external calls with retries and checkpointing.

Outcome:

• No worker cluster.
• No custom rate limiting or concurrency infrastructure.
• Clear Traces and structured logs for each tenant’s sync.

---

Observable Cron: Traces, Logs, and Replay

You can’t trust a scheduler you can’t see. One of the reasons I stopped tolerating DIY cron infra was the post-incident workflow: grep logs, stitch together trace IDs, hope you don’t miss a partial run.

With Inngest:

• Every run of your scheduled function appears in Traces.
• Each step shows:
  • inputs,
  • outputs,
  • execution duration,
  • errors (if any), as structured data.
• You can:
  • filter runs,
  • inspect a particular tenant’s failure,
  • Replay failed runs or even “good” runs to reproduce complex edge cases.
  • Bulk cancel or replay thousands of runs when you need to remediate.

This is especially useful for:

• Billing jobs (replay after fixing a bug in tax logic).
• Notification digests (cancel a noisy batch).
• AI workflows (see and re-run every prompt/response pair).

You get production-grade observability without plumbing Datadog dashboards or custom admin UIs on day one.

---

Local Development: Scheduled Tasks You Can Actually Run Locally

Most cron solutions force you to “just wait” for production schedules, or invent custom flags to run jobs manually in dev.

Inngest ships a dev server you can start with one command:

npx --ignore-scripts=false inngest-cli dev

This gives you:

• A local Inngest Dev Server that:
  • loads your functions,
  • simulates events and schedules,
  • surfaces Traces locally.
• The ability to:
  • trigger your scheduled function manually,
  • replay events from production,
  • iterate on business logic without touching infrastructure.

Code stays business logic. The dev loop stays fast.

---

Flow Control: Preventing Noisy Neighbors in Scheduled Work

In multi-tenant systems, schedules can be dangerous. One heavy tenant can:

• cause timeouts,
• saturate your database,
• push everyone else’s jobs into backlog.

Inngest’s flow control features are designed to be configured at the function level instead of rebuilt as infrastructure:

• Concurrency keys (e.g., "tenantId" or "accountId") ensure one run per key at a time.
• Throttling lets you cap how many runs execute concurrently across the function.
• Prioritization lets you promote urgent work without rewriting application logic or introducing new queues.

Applied to scheduled tasks, this means:

• Your hourly sync doesn’t stampede your DB when you add a big new customer.
• High-priority incident remediations can be scheduled and run ahead of low-priority housekeeping.

You’re expressing scheduling and flow control in code, not in Terraform and bash scripts.

---

When to Use Cloud Native Cron vs. Inngest

If all you need is:

• “Ping this health check URL every 5 minutes”

then a basic cloud cron (CloudWatch Events / EventBridge / Cloud Scheduler / Cloudflare Cron Triggers) is fine.

Reach for Inngest when:

• The job is multi-step (e.g., fetch → transform → store).
• Failures create partial state.
• You need per-tenant control (concurrency, throttling).
• You want traceability, replay, and bulk operations.
• You don’t want to own workers, queues, and dead-letter recovery.

This is the line between “timer” and “durable scheduled workflow.” Inngest is built for the latter.

---

Putting It All Together: Scheduled, Durable, Worker-Free

To schedule recurring tasks (cron) in a serverless app without running your own worker servers:

1. Stop trying to run cron inside your serverless runtime.
   Timeouts and ephemeral instances make it brittle at best.

2. Use Inngest to declare schedules in code:

   • cron: "0 2 * * *" for classic cron expressions.
   • Functions defined with inngest.createFunction().

3. Break work into durable Steps with step.run():

   • Automatic retries and checkpointing.
   • Resume from the last successful step on failure.

4. Apply flow control for multi-tenant safety:

   • Concurrency keys, throttling, and prioritization.

5. Rely on Traces, Replay, and Bulk Cancellation for operations:

   • Debug and remediate without building your own tooling.

You get recurring, reliable, observable tasks—without owning workers, queues, or custom cron infrastructure.

---

Next Step

If you’re ready to replace fragile cron jobs and DIY workers with durable, observable scheduled functions, you can talk through your use case and see how Inngest would fit your stack:

Get Started