What is ‘Apex CPU Time Limit Exceeded?’

If you’ve ever encountered the error message, “Apex CPU time limit exceeded,” you’ve run afoul of Salesforce’s timeout limit for transactions based on CPU usage. The message indicates your transaction is taking too long and, therefore, has been shut down, with all completed and in-process tasks reverted. Not only can it affect data accuracy, timeliness and, eventually, speed to lead, it’s also a signal you likely have bigger root problems in your Salesforce org. 

What is causing the CPU time limit error?

Salesforce imposes a CPU usage governor limit for every given execution context, from 10 seconds for synchronous transactions to 60 seconds for asynchronous transactions. Simply, the combination of your Apex code and any declarative tools, including AppExchange packages, must not exceed those systemic limits.

Hour glass with sand dropping from the top to the bottom.

CPU timeouts primarily occur in two very different situations. First, in a relatively simple process, you attempt to process too many records at once, resulting in your code hitting the processing limit. The second situation involves processing a smaller number of records through a process too complex for Salesforce to handle within its CPU time limits. All that being written, your CPU time is a simple function of the number of records multiplied by the time to process.

CPU time = (# of records) x (time needed to process)

Conducting a Salesforce CPU audit

You should conduct periodic Salesforce CPU audits even if you’re not currently experiencing timeout errors. It’s always a good practice to discover what consumes the majority of your CPU time, and a good audit is absolutely necessary if you’re looking to scale.

Use the following steps to conduct your own CPU audit (If you’re not already a LeanData customer, ensure you’ve first enabled the live Debug Log):

1Access the Developer Console

Setup menu in SFDC 2 – Select a log from the “Logs” tab

3 – In the Debug menu on the top navigation bar, select Switch Perspective and then Analysis (Predefined)

4 – Select Timeline, then choose your relevant Scale

Given the resulting timeline view, you will be able to see the execution sequence for your Apex, Workflow and Database actions, and how much time each consumes. With that data, you can then dive deeper into the details of what actions are consuming too much of your CPU time. The best place to start is to investigate the creation of leads, contacts and accounts, determining how long the system takes to run Apex code, validation rules, workflow rules, process builders and database queries.

How to solve Apex CPU time limit errors

If you’re hitting Apex CPU time limit exceeded errors, the quick, relatively easy fix includes:

  • process your manual inserts in smaller batches
  • schedule your automation to run only when and where needed
  • control your batch size in automated updates.

For more complex processes, there are a variety of possible root causes and corresponding solutions, and an overview of each is provided below. 

Process Builder most often causes CPU timeout errors when there are multiple processes per Object. Best practice is to consolidate multiple processes into only one process per Salesforce Object. One possible solution is to migrate your automation from Process Builder to an Apex trigger, as triggers often work faster and are less prone to produce an error. However, Apex triggers are more difficult to build, and often require developers who have experience with complex coding. 

Flows often cause CPU timeout errors when they happen after save rather than with the before save flow feature from SFDC’s Spring 2020 release. Migrate your existing flows to the new model and select the before save option upon the creation of your flow.

There are many situations where Apex code causes CPU timeout errors, including the following: 

  • Inefficient filters when looping or diving into nested layers of a loop can lead to higher processing costs. The loops and layers are not the real issue, but an unfiltered/poorly-filtered list of records adds unnecessary operations to records, as an excess of data might be getting pushed further into nested loops. Every nested loop that doesn’t first filter the data enough is going to add another operation to excess data. So, poor filtering in nested loops could lead to exponentially higher CPU demands.
  • Multiple triggers require more processing; limit the number of triggers fired on one update.
  • Circular updates between two objects result in a continuous, never-ending execution loop and, eventually, a CPU timeout. Rewrite to eliminate the loop.
  • Querying and updating the same object multiple times wastes resources; implement a practice of one update on one object.
  • Updates that call the same update trigger more than once within a transaction are unnecessary. Eliminate multiple calls in a transaction.

Blocks from a child's playroom.

Lastly, managed packages from the AppExchange can be disproportionately consuming your resources. While AppExchange packages receive an increase for a lot of different Salesforce limits, CPU time is not one of them. A managed package shares the same CPU pool with everything else in your Salesforce organization. You cannot edit the code of most managed packages, so it’s critical to only keep packages in your instance that add value and uninstall those that are no longer needed.

Optimize your Salesforce instance to avoid APEX CPU Time Limit Errors

LeanData recognizes your business relies on Salesforce. When your SFDC org slows down, it affects your ability to go to market and likely increases your time to revenue.

Salesforce is a shared resource, with multiple customers, applications and ISV (Independent Software Vendor) partners all running on top of it. Everyone and everything competes for scarce resources, and Salesforce has systems to deal them out in allocation. 

The challenge for any SFDC customer looking into performance issues – the speed of Salesforce – is that SFDC does not provide the visibility, tools and diagnostics for you to easily understand what’s happening. And, that is critical, for we all need to understand and address the root causes of problems, not symptoms.

As mentioned above, a great place to start to understand root causes of slow performance is an audit using a debug log. While it takes a technical understanding of Salesforce, it does shed light into what’s taking up your scarce SFDC resources. Watch out for your own customizations: Salesforce does not protect you from yourself!

Within LeanData’s role as a Salesforce ISV partner, we take seriously our responsibility to act as a discerning steward to the entire SFDC ecosystem. We write our app’s triggers to be lightweight, and asynchronous processing is utilized to ensure that LeanData has minimal impact to your record update CPU load.   

Also, within the LeanData lead-to-account Matching and Routing products, specific user tools allow you, the customer, to prioritize the handling of different objects and lead types, ensuring your hottest leads, like a demo request, are fast tracked, while lower priority leads, like trade show booth visitors, are processed later. The end result is a judicious and prudent use of SFDC resources.

When it comes to Salesforce, we are all – literally – in this together. While SFDC is the preeminent CRM, it does present its occasional challenges, and CPU time limit exceeded errors are the biggest thorns. Use the tips above to eliminate those obstacles and get your go-to-market motions back on track!

Monica Bacican
Sr. Sales Operations Manager at LeanData

Monica Bacican is a Senior Sales Operations Manager at LeanData, where she uses her analytic abilities and strong relationship-building skills to reduce friction, remove bottlenecks and improve revenue team processes. Connect with Monica on LinkedIn and Twitter.