Background Processing

Work that outlives the request, from one handler file. In NetScript, moving work off the request path means authoring a single typed handler — the queue, retry policy, scheduler, execution history, trigger API, and OpenTelemetry traces come from the worker runtime, so there is no separate queue-and-worker stack to assemble (or to explain to an AI agent) before the first job runs.

Two page-level stories anchor this pillar. Background jobs opens with a production one: a vision job that turns a pasted alert-email screenshot into structured diagnosis fields — and the two contract properties (queue-borne payloads, compute-only workers) that shaped it, plus a factual side-by-side with Trigger.dev and Temporal. Polyglot tasks covers the step that is not TypeScript: an existing Python, .NET, or shell script that keeps its language and gains the same queue, retry, and trace behavior as everything else.

Background Processing covers worker tasks, queue providers, scheduled work, runtime adapters, and per-task permissions. Start here when work should run outside the request path but does not need the durable saga state model — for that, see durable workflows.

Overview & Concepts Workers and queues

Worker tasks consume queued work with provider and runtime choices kept inside the leaf.

Quickstart Polyglot transform

Run a task step from the ERP Sync tutorial.

How-To Queue, KV, and cron

Create the queue and scheduler loop used by background work.

How-To Choose a queue provider

Select the provider that fits your local and deployed runtime.

How-To Run a polyglot task

Execute work in a non-TypeScript task runtime.

API Reference workers, queue, cron

Generated symbols for task, queue, scheduler, and watcher packages.