Salesforce enforces governor limits to ensure that no single Apex transaction monopolizes shared server resources. One of these limits is the CPU time limit: Salesforce allows a maximum of 10,000 milliseconds (10 seconds) of CPU time per synchronous Apex transaction and 60,000 milliseconds (60 seconds) per asynchronous Apex transaction.
When an Apex transaction — including all triggered Apex code, workflow rules, validation rule formula evaluations, and managed package code — consumes more CPU time than the allowed limit, Salesforce throws the "Apex CPU time limit exceeded" error and terminates the transaction.
CPU time is measured only for processing that occurs on the Salesforce application server. Database operations such as SOQL queries, DML statements (insert/update/delete), SOSL searches, and the time spent waiting for external API callouts to return are not counted toward the CPU time limit. Time spent on Apex code compilation is also not counted.
Understanding what is and is not counted helps developers optimize their code to avoid hitting this limit.
You can refer to Apex Code Best Practices for a comprehensive guide. Key optimizations are described below.
A common source of unnecessary CPU time is using a for loop to iterate over a list of records in order to build a Set of record IDs. Each iteration of the loop consumes CPU time proportional to the number of records.
A more efficient approach is to query records directly into a Map using the Map constructor with a SOQL query. For example, querying Account records into a Map of ID to Account automatically provides both the Set of IDs (via the keySet() method) and the List of Account records (via the values() method) — without any additional looping. Map-based queries also support retrieval of up to 50,000 records, compared to the 10,000 record limit for standard list queries.
In some cases, a business process does not need to execute in real time. If code can be executed asynchronously (for example, using the @future annotation or Queueable Apex), this breaks the transaction context and also grants a much higher CPU time limit of 60,000 milliseconds (6 times the synchronous limit). Consider this approach if your synchronous code is at risk of hitting the CPU limit.
Since database processing time is not counted toward CPU time, it is more efficient to perform calculations at the database layer using SOQL aggregate functions such as SUM(), COUNT(), AVG(), and GROUP BY, rather than retrieving all records and performing the same calculations in Apex code with a for loop.
For example, to calculate the total value of all Opportunity records for an Account, use a SOQL query with SUM(Amount) rather than querying all Opportunities into a list and summing the amounts in a loop.
Retrieving more data than necessary increases the size of your loops and the amount of processing performed. Always filter SOQL queries to retrieve only the specific records and fields required for the operation, and avoid SELECT * patterns.
000387833

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.