Scheduled Jobs
Scheduled Jobs is a Salesforce Setup page that lists every job set to run on a timer in your org.
Definition
Scheduled Jobs is a Salesforce Setup page that lists every job set to run on a timer in your org. It brings scheduled Apex classes, dashboard refreshes, report and analytic snapshots, and other timed processes together in one read-only monitor, so you can see what is scheduled, who scheduled it, when it last ran, and when it runs next.
You reach it from Setup by typing Scheduled Jobs into Quick Find. The page does not let you create a schedule. It shows what already exists and gives you a Del link to cancel any job you no longer want. For an admin asking "why did this run at 3 a.m.?", this page is usually the first place to look.
How the Scheduled Jobs monitor fits your org
What actually lands on the page
The Scheduled Jobs list is a roll-up of several different timed features, not just Apex. You will see Scheduled Apex classes submitted through System.schedule or the Apex class scheduler UI. You will also see dashboard refreshes that subscribers or admins set to run on a cadence, report and analytic snapshots (sometimes still called reporting snapshots), and other platform jobs that Salesforce queues for a future time. Each row carries a Job Type column so you can tell a Scheduled Apex entry from a Dashboard or Snapshot entry at a glance. Because so many features funnel into one screen, the page can grow long in a mature org. That is exactly why it is useful. Instead of hunting through Apex, reporting, and dashboard areas separately, you get a single timeline of everything the platform plans to do. The trade-off is that the page mixes concerns, so reading it well means knowing which Job Type maps to which feature and which team owns it. Treat the list as an inventory, not a control panel, since most of the real configuration lives in the feature that created the job.
Reading the columns and statuses
Each scheduled job shows a handful of fields that answer the questions admins ask most. Submitted By tells you which user owns the schedule, which matters because the job runs in that user context and inherits that user's access. Job Type identifies the kind of work, such as Scheduled Apex or Dashboard. Submitted Date records when the schedule was created, and Next Scheduled Run tells you the next fire time so you can predict load. After a run, you can also see status information that tells you whether the last execution finished or failed. The owner detail is easy to overlook and important. If the user who scheduled a job is deactivated, the job can stop running or behave oddly, because Salesforce ties the execution to that running user. When you audit the list, scan the Submitted By column for people who have left. A job owned by a former employee is a quiet risk, since nobody is watching it and the context it runs under may no longer be valid. Document the owner and purpose for anything business critical.
Scheduled Apex and the 100-job ceiling
The most common reason developers care about this page is the Apex Scheduler limit. Salesforce lets you have at most 100 scheduled Apex jobs at one time, counted across the whole org. Hit that ceiling and new System.schedule calls fail, which can break deployments and runtime logic that schedules work dynamically. The Scheduled Jobs page is the canonical way to check your count. Create a custom list view filtered to Job Type equals Scheduled Apex, and the row count is your current usage against the 100 limit. You can also query the CronTrigger and CronJobDetail objects in Apex or SOQL to get the same number programmatically, which is handy inside guard logic before you schedule more. Keep in mind a separate cap on how often scheduled Apex can fire. The maximum number of scheduled Apex executions in a 24-hour window is 250,000, or the number of user licenses in your org multiplied by 200, whichever is greater. Watch both numbers. The 100-job limit governs how many schedules can exist, while the daily execution cap governs how many times they all run together.
Why old schedules pile up
Scheduled jobs accumulate because nothing forces anyone to clean them up. Someone schedules a one-time cleanup class, the cleanup finishes, and the schedule keeps firing for years because no one descheduled it. A test schedule added during a sandbox refresh or a data migration survives into production and quietly burns one of your 100 Apex slots. A dashboard refresh set up for a project that ended still wakes up every morning. None of this throws an error, so it stays invisible until you go looking. The cost is real even when nothing breaks. Every stale Scheduled Apex job eats a slot you might need later, and every unnecessary refresh adds load at a fixed hour. The fix is a routine, not a one-off. Skim the page on a regular cadence, investigate any Job Type or owner you do not recognize, and delete what no longer has a reason to exist. A quarterly pass is usually enough to keep the list honest and to keep a surprise from showing up the day you try to schedule something new.
Deleting versus aborting a job
There are two ways to stop a scheduled job, and they are not the same. From the Scheduled Jobs page you click the Del link next to a row, which unschedules that job so it never fires again. This is the right move for a schedule you want gone permanently, such as an orphaned cleanup class or a project dashboard that retired. The Del link removes the future schedule cleanly and frees the slot if it was Scheduled Apex. The other path is aborting a job that is already running or queued, which you do in Apex with System.abortJob and the job's CronTrigger Id. Aborting is about stopping an in-flight or imminent execution rather than tidying the schedule list. In practice admins reach for the Del link, and developers reach for System.abortJob inside automation or a quick anonymous block when they need to kill a job by Id. Either way, removing a schedule does not roll back work the job already did. If a job altered records on earlier runs, deleting the schedule only prevents future runs. Treat cleanup of the data and cleanup of the schedule as two separate tasks.
Pairing it with the other job monitors
Scheduled Jobs answers "what is set to run later," but it is only one of several monitoring pages, and admins get confused when they expect it to show everything. It does not show the live queue of Apex that is running right now. For that you use the Apex Jobs page, which lists batch, future, and queueable executions and their pass or fail status. Background Jobs is yet another view for certain platform operations. The clean mental model is timeline versus activity. Scheduled Jobs is the timeline of future work, while Apex Jobs is the activity log of recent and in-progress async work. When you debug a problem, you often start on Scheduled Jobs to confirm a job is even scheduled, then jump to Apex Jobs to see whether its last run actually completed. Keeping the two straight saves a lot of wasted time. A schedule can look perfectly healthy on the Scheduled Jobs page while its executions are silently failing on the Apex Jobs page, so check both before you conclude that a timed process is fine.
Audit and clean up the Scheduled Jobs page
You cannot create a schedule on the Scheduled Jobs page, but you can use it to audit what exists, measure your Scheduled Apex usage against the 100-job limit, and remove jobs you no longer need.
- Open the page
From Setup, type Scheduled Jobs into the Quick Find box and select Scheduled Jobs. The full list of timed jobs in the org loads.
- Create a Scheduled Apex view
Click Create New View, add a filter where Job Type equals Scheduled Apex, and save. The row count of this view is your current usage against the 100-job ceiling.
- Identify owners and purpose
Scan the Submitted By and Submitted Date columns. Flag any job owned by a deactivated user or any Job Type you do not recognize for follow-up.
- Delete what is stale
Click the Del link next to a job that has no reason to run. The schedule is removed and, for Scheduled Apex, the slot is freed for reuse.
Filter a custom view to Scheduled Apex, Dashboard, or Snapshot so you can review one category of timed job at a time.
The user the job runs as; deactivating this user can stop or break the job, so reassign or reschedule critical jobs first.
Unschedules a single job permanently. It does not undo work already performed on earlier runs.
- The page is read-only for creating schedules; build new schedules in Apex, the dashboard subscription UI, or the snapshot setup, not here.
- Deleting a schedule only stops future runs. It does not reverse data changes the job made on previous executions.
- A job owned by a deactivated user may quietly stop running, so check the Submitted By column before you deactivate anyone.
- Scheduled Jobs shows future work only. To confirm a recent run actually succeeded, check the Apex Jobs page instead.
Trust & references
Cross-checked against the following references.
- Apex Scheduler (Apex Developer Guide)Salesforce
- Monitoring Scheduled Jobs (Salesforce Help)Salesforce
Straight from the source - Salesforce's reference material on Scheduled Jobs.
Hands-on resources to go deeper on Scheduled Jobs.
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. Why is understanding Scheduled Jobs important for Salesforce admins?
Q2. Can a Salesforce admin configure Scheduled Jobs without writing code?
Q3. What is the primary benefit of Scheduled Jobs for Salesforce administrators?
Discussion
Loading discussion…