solutions

Background jobs
without a queue to babysit.

Ship a Python or Node.js function — a whole directory bundle, dependencies and all — and attach a cron expression. Nightly reports, syncs, cleanup, digests: every run executes in a fresh, isolated Firecracker microVM and is destroyed when it exits.

1 VM
per run
1-min
finest granularity
0
workers to manage
schedule: "*/15 * * * *"
ship it

Point a cron at a function.

A background job here is two commands: deploy the bundle, create the schedule. Standard 5-field cron — every-5-minutes sweeps, 09:00 UTC reports, Monday-midnight digests. Change the cadence later with a schedule update; the function never redeploys.

Cron you already know

Schedules attach a plain cron expression to a function id — no DSL, no YAML pipeline. You can even pre-register a function and wire up its schedule before the first bundle is pushed; it starts firing the moment the code lands.

*/5 * * * *0 9 * * *0 0 * * 1
shell — pandastack cli
# ship the job as a function bundle
pandastack fn deploy ./nightly-report/ \
  --name daily-report \
  --runtime python \
  --entrypoint handler.py

# put it on cron — every day at 09:00 UTC
pandastack schedule create \
  --name daily-report \
  --fn <function-id> \
  --cron "0 9 * * *"

# backfill or verify right now, no waiting
pandastack schedule trigger <schedule-id>
pandastack schedule runs <schedule-id>
isolation

Every run gets a brand-new machine.

There is no long-lived worker chewing through a queue. Each scheduled run boots its own microVM, executes the function, and vanishes — the same clean-slate execution as a manual invocation, behind hardware virtualization.

Fresh runtime, every time

No shared state between runs and no noisy neighbours. Dependencies install from requirements.txt or package.json on each run — or bake heavy ones into a custom template once.

Stuck runs stay stuck alone

A hung or crashed run can't poison the next one — it dies with its VM. Even kill -9 can't escape the sandbox boundary.

No pool to size or drain

Nothing runs between windows, so there's no fleet to scale, patch, or gracefully drain on deploy. Between runs your job costs $0 while idle.

operate

Know that it ran, not just that it was scheduled.

Cron's classic failure mode is silence. Every scheduled invocation lands in run history and in golden metrics — latency percentiles, error rate, cold-start rate — recorded automatically in ClickHouse.

Run history

List every run of a schedule or function. Deploys are versioned and old bundles are kept, so a run traces back to the exact code that produced it.

Golden metrics

p50/p95/p99 latency, error rate, and cold-start rate per function — one CLI command or a REST call away.

Trigger on demand

Fire a schedule manually for backfills, or to test a cron-backed workflow immediately instead of waiting for the next window.

Pause & resume

Pausing keeps the schedule definition but stops future automatic runs — resume when the incident is over. No crontab surgery.

built from

Two primitives, wired together.

Background jobs aren't a separate product — a schedule is a cron expression pointed at a function. Everything each primitive can do, your jobs can do: env updates without redeploys, public HTTP endpoints, custom templates.

Ship on the millisecond cloud.

Free tier with $5.40/mo usage credit. No card. Apache-2.0.