Skip to content
Get started
Get started
Adding Jobs: Priorities, Delays and Bulk
guide · queue

Getting work into the queue.

One job or a hundred thousand, ordered by priority, held back by a delay, or written straight to disk when losing it is not an option.

const basicJob = await queue.add('job-name', { key: 'value' });
// With options
const configuredJob = await queue.add('job-name', data, {
priority: 10, // Higher = processed first
delay: 5000, // Wait 5s before processing
attempts: 5, // Max retries if the processor throws (default: 3)
backoff: 2000, // Wait between retries in ms (default: 1000, jitter applied)
// OR: backoff: { type: 'exponential', delay: 2000 } // 'fixed' | 'exponential'
timeout: 30000, // Fail the job if processing takes longer
jobId: 'custom-id', // Custom ID, makes the add idempotent (see Deduplication)
removeOnComplete: true, // Delete job data after it completes
});

The full option list is in the reference table.

timeout starts when the broker marks the job active. The broker tracks the absolute processing deadline and fails the job with reason timeout when it is reached; it is not rounded to a maintenance sweep interval.

addBulk inserts all jobs in one batch, much faster than a loop of add:

const jobs = await queue.addBulk([
{ name: 'task-1', data: { id: 1 } },
{ name: 'task-2', data: { id: 2 }, opts: { priority: 10 } },
{ name: 'task-3', data: { id: 3 }, opts: { delay: 5000 } },
]);

addBulk is ordered and uses accepted-prefix semantics; it is not an all-or-nothing flow transaction. If a later entry is rejected, earlier entries that were already accepted remain in the queue and later entries are not evaluated. The rejected entry itself is never left as a hidden in-memory job. Use FlowProducer when the whole graph must commit atomically.

// Every 5 seconds
await queue.add('heartbeat', {}, { repeat: { every: 5000 } });
// Every 24 hours, at most 30 times
await queue.add('daily-report', {}, { repeat: { every: 86400000, limit: 30 } });
// Cron pattern
await queue.add('weekly', {}, { repeat: { pattern: '0 9 * * MON' } });

You can change the data for future runs at any point in the lifecycle with updateData(), even after the current run completes (the update follows the repeat chain to the next scheduled execution):

const job = await queue.add('sync', { endpoint: '/api/v1' }, { repeat: { every: 60000 } });
await job.updateData({ endpoint: '/api/v2' }); // Next run uses /api/v2

For named, managed schedules, see Job Schedulers and the Cron guide.

By default bunqueue batches writes to disk every 10ms for speed (~100k jobs/sec). A crash inside that window can lose the not-yet-flushed jobs. For jobs where that is unacceptable, durable: true writes to disk before add() returns:

await queue.add('process-payment', { orderId: '123', amount: 99.99 }, {
durable: true,
});

Durable acceptance is fail closed. add() resolves only after SQLite commits the job and any related custom-ID retirement, dedup replacement, dependency pin, or parent link. If SQLite rejects the write—for example because the disk is full—the call rejects and that candidate is not queryable, counted, or available to a Worker. Reusing a completed or DLQ jobId is also atomic: a failed replacement preserves the previous generation and its result across a broker restart. The same contract applies in Embedded and TCP mode and to durable entries in addBulk.

ModeThroughputData loss windowUse for
Default~100k jobs/secUp to 10msEmails, notifications, analytics
Durable~10k jobs/secNonePayments, orders, audit records
Queue APICreate a queue in embedded or TCP mode
Deduplication and Idempotent Job AddsIdempotent adds, dedup keys, custom job ids
Querying JobsFetch jobs, states, counts and results
Queue Control and MaintenancePause, drain, obliterate, clean and repair
Progress, Job Logs and DependenciesProgress, per-job logs and dependencies
Queue Rate Limiting and Global ConcurrencyRate limits and global concurrency caps
Job Schedulers from the QueueNamed repeatable schedules from the queue
DLQ Operations from the Queue ObjectFailed-job operations from the Queue object
Workers, Stats and Metrics from the QueueRegistered workers, stats and metrics windows
Namespaces, Auto-Batching and Store-and-ForwardNamespaces, auto-batching, store-and-forward
JobOptions ReferenceEvery JobOptions field, with defaults