Use cases · Workers and scheduled jobs
Background work in productionSame workflow as the app
Workers and cron follow the same path as the app they support.
web
healthy
GET / 200 · customers see this
then
worker
same workspace
queue + cron · same deploy history
In the product
The job scales on its own.
Set replicas and limits, then read the logs. The schedule stays on the service.
Before
The HTTP surface looks fine. The job does not.
The web process is healthy on one host. The cron still lives on a leftover box.
web · 200
Customers see a healthy app.
leftover
cron on leftover-box
0 2 * * *
Only one engineer knows which machine owns 2am.
Path
The job runs next to the app.
The job is a first-class process, not a script behind the request.
01 · enqueue
job.created
The API writes the job. The worker is next to it.
02 · run
worker process
Own CPU, memory, and replica count.
03 · result
job.complete
Logs stay on the worker service.
Capacity
Jobs get their own limits.
Background work rarely matches the web process. Set resources on the job.
cpu
memory
Schedule
Cron lives on the service.
Expression, last run, and next run sit beside the worker logs.
nightly-settle
0 2 * * *
last
02:00 UTC
next
tomorrow
jobs
Run the worker.Stay on the product.
0 2 * * *
Use dFlow when the work behind the request needs the same production clarity as the request.