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.