The work nobody is watching.
A queue job, a scheduled job, and a long job all run with no browser waiting on them. This page names all 3 and says where each one runs. It also splits who owns whether a job is safe to run twice.
Three kinds of work run with no browser waiting
Each one starts differently. This page keeps them apart on purpose.
The queue job
Resize an uploaded image. Generate a PDF receipt.
- Starts with
- A request that hands the work off instead of making a visitor wait for it.
The scheduled job
A nightly report. A cleanup that runs once a day.
- Starts with
- A clock, not a request. It runs at a set time, whether or not anyone is looking.
The long job
A four-minute import. A bulk export of a year of records.
- Starts with
- A request, but one too slow to answer inside a normal request-response window.
Where a job runs, hop by hop
No job runs inside the same process that answers a request. That is the point of handing it off.
- 1
The web process returns at once
A request that triggers a job does not wait for it. The answer comes back first, and the work happens after.
CustomHosted
- 2
The job goes to a queue, or a clock fires it
A queued job waits its turn. A scheduled job waits for its set time instead.
CustomHosted
- 3
A standing worker process picks it up
Running continuously, separate from the web process, watching for work rather than waiting for a request.
CustomHosted
- 4
A process manager restarts the worker if it dies
A crashed worker does not stay down. It is brought back automatically, the same as any other process on the instance.
The process manager
- 5
The job writes a line
What it did, and whether it worked. The same record class Logs already covers.
You
What runs a job, by hosting shape
One of these three shapes cannot run a job at all. The table says which, and why.
| Shape | Plan | What runs it | Detail |
|---|---|---|---|
| Static | Static Starter | Nothing | A static site has no server process at all. There is nowhere for a job to run. That is why a job needs a dedicated instance instead. |
| Dedicated | Dedicated S | The web process, the worker, and the clock, on one instance | Sized and billed as one line item on the Dedicated S tier and up, not a per-invocation meter. |
| Custom | Custom | A separate worker fleet | Designed to the workload and quoted flat, the same as any other Custom shape. |
The clock
How a scheduled job is wired in, the timezone it keeps, and the two anxieties readers actually have.
Wired in on day one, not a manual step
A scheduled job is set up as part of provisioning. It does not wait for someone to remember to add it later.
Runs on UTC
Every scheduled job on this platform keeps the same clock. Stated plainly here, since you cannot check it yourself otherwise.
Two runs that overlap
A slow job can still be running when its next run is due. The clock does not skip a run to make room for it. Tell us if a job must never run twice at once, and we set it up to wait its turn instead.
A run that misses its window
A crashed worker or a stuck queue can stop a job from starting at all. It is retried once automatically. See "When a job fails" below for what happens next.
When a job fails
The same watch list and ladder as Monitoring, filtered to the two layers that bear on a job.
| Layer | Signal | What fires it | First response | Auto or human |
|---|---|---|---|---|
| Background jobs | Queue liveness and scheduled-job completion | A queue backing up with nothing consuming it, or a scheduled job that starts but doesn't finish inside its window | Retried once automatically; a repeat failure is what pages a human | Auto, then human |
| Process & containers | Process and container health | A crashed process, a hung worker, or a failed health check on a running container | Restarted automatically, logged, and left there unless it keeps happening | Auto |
- 1
Auto-handled
Restart, retry, or redeploy the last known-good version, done automatically
No one, unless it recurs — it goes in the log, not a message to you
- 2
You hear from us
A human looks at it and decides what to do — revert, restore, or a fix in code
You, in writing, on the same quote channel as everything else — business hours for anything that isn’t urgent
- 3
Outage handling
Worked ahead of the routine queue
You, as soon as there is something to say, with priority handling; out-of-hours response is best effort, not a staffed round-the-clock desk
Who owns what
Said plainly, split by who actually holds each half.
CustomHosted
- Keeping the worker process running
- Restarting it if it dies
- Keeping the queue itself alive
- Sending the alert when a job keeps failing
You
- Whether the job is safe to run more than once
- How long the job is allowed to take
- What the job actually does
This site's own recurring work
Every row below is backed by a real file in this repository, not a claim without a receipt.
This site is static. It has no worker and no clock
Nothing here runs continuously. There is no standing process to pick up a queued job or wait for a scheduled one.
The nightly job runs in the deploy pipeline instead
A handful of generators run on every build, computing the numbers this site publishes rather than a person updating them by hand.
A guard fails the build when the output goes stale
Each generator's output is checked against the repository it describes. A build breaks loudly instead of a page quietly drifting from the truth.
The honest trade-off: a fact only refreshes when something ships
With no clock of its own, this site's numbers are only as current as the last deploy. A static plan has the same limit for any other job.
A line item, not a per-invocation meter
A worker is sized and billed once, as part of the plan it runs on. That starts at $29/mo, on the tier where a worker first fits.
A job that runs hot does not move the invoice
Running more often, or for longer, does not add a second charge. The rate is for the worker being there, not for each time it fires.
The honest limits
Not buried in a footnote — the same discipline as every other honesty band on this site.
No autoscaling
A flat rate means fixed, known capacity. Nothing on this platform grows itself in the background and bills you for it afterwards.
No per-job console
There is no dashboard to click through to watch a job run. An extract is a request, sent through the quote channel, the same as a log extract. See Logs for the rest of it.
At-least-once, not exactly-once
A retry can run a job again after a failure. We cannot make your job safe to run twice. That is your half of "Who owns what" above.
A static-only plan cannot run a job
There is no process to run it on. See the hosting-shape table above for the reason.
One instance means one clock
A single dedicated instance runs one scheduler. Running the same job from two clocks at once is a Custom quote, not a default.
Where a failing job becomes a briefed change
A job that fails every night is a code fix, not an ops fix. It ships the same way every other fix on this site does — Agentic iteration — CodeHerder ($25/mo):
- 1
A routine scan flags a dependency
The same kind of check that watches the infrastructure layers above, run against your application’s own dependency list.
- 2
It's triaged as application-level, not infrastructure
A library your own code imports isn't ours to patch silently — it can change how the app behaves.
- 3
Briefed as a change
Written up the same way any other change request is — this is what the Agentic iteration — CodeHerder add-on covers.
- 4
An agent opens the pull request
The upgrade lands as a real pull request against the repository, with the test suite run against it.
- 5
A human reviews and merges
Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.
- 6
It ships through the same pipeline
The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit.
- 7
You're told it's done
A note confirming what changed and that it merged, in the same shape as every other note on this site.
Job questions
The questions that come up once "just add a background job" stops being a one-line decision.
01What counts as a background job?
Anything your app does with no browser waiting on it directly: a queued task handed off from a request, a job that runs on a clock, or a request too slow to answer inline. See the three kinds above.
02Can a job run twice by accident?
A retry after a failure can run a job again. This platform is at-least-once, not exactly-once. Whether a second run is safe is your call, made in the job itself. We cannot guarantee it from underneath.
03What happens if a scheduled job's run overlaps with the next one?
The clock does not skip a run to make room for a slow one. Tell us if a job must never run twice at once. We set it up to wait its turn. See "The clock" above.
04What timezone do scheduled jobs run in?
UTC, for every scheduled job on this platform. Stated here plainly, since it is not something you could check for yourself otherwise.
05Can I run a background job on a static plan?
No. A static site has no server process, so there is nowhere for a job to run. A static-only plan is the wrong shape for any background work.
06What if a job keeps failing every night?
That stops being an ops problem and starts being a code fix. See "Where a failing job becomes a briefed change" above. It ships through the same pipeline as any other fix, under the Agentic iteration — CodeHerder add-on.
07Does a job that runs constantly cost more?
No. A worker is billed as a line item on the plan it runs on, not by how often it fires. A worker starts at $29/mo, on the tier where one first fits.
What background work connects to
- Monitoring
The watch list and the ladder this page's "when a job fails" section reuses in full.
- Logs
Where the line a job writes actually goes, and how long it is kept.
- Dedicated
The instance a worker and a clock actually run on.
- Custom
A separate worker fleet, designed and quoted flat, once one instance is not the right shape.
- Scaling
The "No autoscaling" limit this page's honest limits reuse whole.
- Email
What a worker actually sends, once it decides to send mail: the path and the records it needs.
- Billing
The invoice this page's "line item, not a meter" fact resolves to.
A job that keeps failing, or a workload that needs one?
Brief it through the same quote channel as any other request — an agent opens the pull request, a human merges it, and the same pipeline ships it.