What is a background job?
Everything slow, risky or scheduled belongs here: out of the user's way, and able to try again.
In short
A background job is a piece of work an application does outside the request a user is waiting on, such as sending an email, resizing an upload or syncing with another service. Jobs are placed on a queue and run by separate workers, which can retry a failed job without the user ever seeing an error or a spinning page.
Also called: Job queue, Async task, Worker
Why it matters when your prototype goes to production
Prototypes tend to do everything inside the request: click send, and the page waits while the app emails 2,000 subscribers. It works with five. With real volume the request times out halfway, and nobody knows which emails went.
A background job turns that into a recorded unit of work. The request only has to put the job on the queue. A worker does the job, marks it done, and retries it if it fails. Because a retry can repeat work, jobs need to be idempotent.
What it looks like in practice
Inkwave sends each newsletter as a durable workflow, in batches of 100 recipients, and records every batch as done exactly once, so a retry picks up where it stopped and never re-sends. Ekko's operator console shows its job and webhook backlogs alongside incidents, so a stuck queue is visible to the people running the platform.
Common questions
What is the difference between a background job and a cron job?
A cron job runs on a schedule, such as every night at 2am. A background job runs when something asks for it. Many apps use both, often through the same queue.
Related terms
Read next
More on this: Production architecture & security · All glossary terms
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.