Background work
The jobs queue, and how much of it runs at once.
Slow work leaves the request: ingestion, syncs, eval runs, and scheduled agent runs all queue on the per-tenant background queue, and the worker process runs them. Jobs is the ops view over that queue.
Jobs
The queue holds every background job type newest-first: source and folder processing, scheduled and trigger-fired agent runs, eval runs, and datasource syncs. Work someone is waiting on — an upload, a "process now" — runs ahead of syncs and reindexes nobody is watching. Each row resolves names on read (a deleted agent never blanks the queue), freezes its payload at enqueue so it can't go stale, and shows progress, attempts, and failure reasons.
Operations: paginated list and detail need job:read (members have it); retry,
run-now for a delayed job, and remove (not-running only) need job:update /
job:delete (owners and admins). Completed jobs display-cap at the newest 10
per page — retention in Redis is unaffected.
How much runs at once
Each organization may run a limited number of jobs at a time, by plan:
| Plan | Processing and agent runs | Datasource syncs |
|---|---|---|
| Free | 2 | 1 |
| Basic | 3 | 1 |
| Starter | 3 | 1 |
| Pro | 4 | 1 |
| Enterprise | 8 | 1 |
"Processing and agent runs" covers source and folder processing, scheduled and trigger-fired runs, and eval runs. One sync at a time on every plan is about correctness: a scheduled sync and a manual "Sync now" never overlap.
These are ceilings, not reservations, and each worker process also caps every
kind at 4 by default — so a self-hosted install raises the worker's own limits
(INGEST_CONCURRENCY, DATASOURCE_CONCURRENCY) before the Enterprise numbers
take effect. A job over its limit waits in the
queue rather than holding a slot.