Background Jobs
Background Jobs in Salesforce are asynchronous units of work that run outside the user's interactive transaction: scheduled Apex jobs that fire on cron schedules, Queueable Apex jobs queued from another transaction, future methods that run shortly after the calling transaction commits, Batch Apex jobs that process large record sets in chunks, and the various platform-managed jobs (sharing recalculation, index rebuilds, mass updates).
Definition
Background Jobs in Salesforce are asynchronous units of work that run outside the user's interactive transaction: scheduled Apex jobs that fire on cron schedules, Queueable Apex jobs queued from another transaction, future methods that run shortly after the calling transaction commits, Batch Apex jobs that process large record sets in chunks, and the various platform-managed jobs (sharing recalculation, index rebuilds, mass updates). The Apex Jobs page in Setup is the central monitoring surface; admins use it to see job status, completion time, errors, and to abort stuck or runaway jobs.
Background Jobs let Salesforce process work that does not fit in the synchronous transaction model: long-running data processing, scheduled maintenance, callouts that exceed the synchronous timeout, bulk record updates that exceed governor limits. They have their own governor limits (different from synchronous limits), their own monitoring surface, and their own debugging considerations. Most production Salesforce orgs run dozens to hundreds of Background Jobs per day; understanding the queue, the prioritization, and the failure modes is core admin and developer knowledge.
Why Background Jobs are the invisible layer keeping production orgs running
The job types and what each is for
Five job types cover most async work. Scheduled Apex runs on a cron schedule (nightly cleanup, weekly reports). Queueable Apex runs as soon as the queue has capacity, supports chained execution, and is the modern replacement for future methods. Future methods run shortly after the calling transaction; mostly legacy with Queueable preferred. Batch Apex processes large datasets in chunks (start, execute, finish methods) and is the right tool for data migrations, mass updates, integration syncs. Platform-managed jobs (sharing recalculation, index rebuild, mass update) are triggered by admin actions and run on the platform's schedule.
Where Background Jobs surface in Setup
Setup, Environments, Jobs, Apex Jobs lists every async Apex execution in the recent past (default 7 days, configurable). Each row shows the job type, status (Queued, Preparing, Processing, Completed, Failed, Aborted), the calling user, start and finish time, total batches processed, and error messages. Apex Flex Queue shows queued jobs waiting for execution slots. Scheduled Jobs shows all active Apex jobs on a cron schedule. Each surface answers a different operational question; using all three together is the production monitoring pattern.
The governor limits that matter for async
Async governor limits are different from synchronous. Async transactions get higher CPU time limits (60 seconds vs 10), higher heap size (12 MB vs 6), more SOQL queries (200 vs 100), and longer total execution time. Batch Apex gets per-batch limits applied independently to start, execute, and finish. The higher limits make async the right tool for work that bumps against synchronous limits; they also make async failures harder to debug because the immediate error is "uncaught exception" rather than "limit exceeded with details". Always wrap async code in try-catch and log to a custom object or to Platform Events for debuggability.
Scheduled jobs and the cron syntax
Scheduled Apex uses cron expressions (seconds, minutes, hours, day-of-month, month, day-of-week, year) to specify when the job runs. A nightly 2 AM run is "0 0 2 * * ?". A weekly Monday 8 AM run is "0 0 8 ? * MON". The expressions are powerful but easy to get wrong; common mistakes include "every 5 minutes" (Salesforce caps at every hour for free-tier scheduling; sub-hour requires Queueable chained with sleep) and time zone confusion (cron runs in the org's time zone, not the user's). Most orgs document scheduled jobs in a spreadsheet with the cron expression, the job's purpose, the owner, and the next review date.
Queue depth, throughput, and the prioritization model
The Apex Flex Queue holds Queueable jobs waiting for execution slots. The queue has a depth limit (typically 100 jobs per org). Beyond the limit, additional Queueable enqueues fail with a LimitException. The platform runs queued jobs as slots become available; concurrency is bounded by edition (Enterprise typically 5 to 10 concurrent jobs, higher for Performance and Unlimited). High-volume orgs design with this concurrency in mind; for sustained high throughput, Batch Apex with appropriate batch sizes outperforms a flood of Queueable jobs.
Failure modes and debugging async
Async jobs fail differently from synchronous. The user is not present, so the error is captured in Apex Jobs rather than shown in the UI. Failures can be silent if the job's error handling swallows exceptions. Common failures: hitting governor limits inside the async transaction, unexpected null fields, downstream Apex changes that broke the job's assumptions, integration timeouts. The debugging pattern: pull the Apex Jobs row, read the Status Detail (error message and stack trace), reproduce in a developer sandbox with the same input data, fix and redeploy. For production-only failures, add structured logging to a custom log object so the next failure is easier to diagnose.
Aborting jobs and the runaway problem
Sometimes a job runs longer than expected, fires more than expected, or makes changes that need to be stopped. Apex Jobs supports Abort on any running job; the abort takes effect at the next safe stopping point (typically the end of the current batch for Batch Apex). Scheduled Jobs supports deleting a scheduled cron entry, which prevents future fires but does not affect the current run. For true runaway jobs (one that keeps re-enqueuing itself), aborting the current run and deleting the schedule both need to happen; aborting without deletion leaves the schedule active for the next fire.
How to monitor and manage Background Jobs in production
The successful pattern: schedule deliberately, monitor proactively, fail loudly, debug methodically. The failed pattern: schedule and forget, discover failures from user complaints, debug from incomplete logs. The Apex Jobs surface plus structured logging plus weekly review covers the operational discipline most orgs need.
- Inventory all scheduled and recurring background jobs
Setup, Scheduled Jobs. Pull the list. Confirm each job has an owner, a documented purpose, and a current review date. Jobs without owners are the most common source of runaway behavior.
- Build a weekly Apex Jobs review
Setup, Apex Jobs. Filter for failed jobs in the past week. Review each, document the cause, decide whether to fix or accept. The cadence catches issues before they accumulate.
- Add structured logging to every async job
Custom log object or Platform Events. Capture job name, run timestamp, input record count, output success and failure counts, error messages on failures. Without structured logging, post-mortem debugging is guesswork.
- Document cron schedules in a shared spreadsheet
Job name, cron expression, time zone, owner, purpose, next review. The Apex Scheduled Jobs page does not have a description field; the spreadsheet is the operational documentation.
- Plan for failure with try-catch and explicit error capture
Async jobs that swallow exceptions fail silently. Every async method should have a top-level try-catch that logs the exception to your structured log before re-throwing or aborting gracefully.
- Build alerts for failed jobs at scale
For orgs with critical background jobs, build a Flow that monitors AsyncApexJob for failures and sends an alert (Chatter post, email, Slack). Manual weekly review catches most issues but misses the urgent ones.
- Quarterly review of cron schedules
Some jobs are still running because nobody reviewed whether they should. Quarterly audit catches obsolete schedules and removes them; the cumulative platform overhead matters at scale.
Scheduled, Queueable, Future, Batch, Platform-managed. Drives the right tool for the work.
For scheduled jobs, the cron syntax that determines when the job fires.
Records processed per execute() invocation. Default 200; tune lower for memory-heavy work, higher for query-heavy work.
Whether the job retries on failure (custom logic) or fails permanently. Most orgs implement retries explicitly in the job code.
Whether failed jobs trigger an alert. Critical for high-value automation; optional for low-stakes cleanup jobs.
- Async governor limits are higher than synchronous but still finite. Jobs that work on 100 records can fail on 100,000 records; test at production scale.
- Cron expressions run in the org's time zone, not the user's. A nightly 2 AM job in a Pacific org runs at 2 AM Pacific, not 2 AM wherever the admin lives.
- Apex Flex Queue has a depth limit. High-volume Queueable enqueues can fail with LimitException; design for the limit or use Batch Apex.
- Failed async jobs are silent to the user. Without alerts, failures are discovered when downstream data looks wrong.
- Scheduled job abort and schedule deletion are two different operations. Aborting stops the current run; deleting the schedule prevents future fires.
Trust & references
Cross-checked against the following references.
- Asynchronous Apex referenceSalesforce
- Background Jobs monitoringSalesforce
Straight from the source - Salesforce's reference material on Background Jobs.
- Monitor Apex JobsSalesforce Help
- Asynchronous ApexSalesforce Developers
- Apex SchedulerSalesforce Developers
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Can a Salesforce admin configure Background Jobs without writing code?
Q2. What is the primary benefit of Background Jobs for Salesforce administrators?
Q3. In which area of Salesforce would you typically find Background Jobs?
Discussion
Loading discussion…