My company is looking to install a very large managed package into our org, which has a significant amount of custom apex as well as several other large managed packages. As we test the package in production, we are running into governor limit issues. Specifically, when closing an opportunity, we are hitting the Apex CPU time limit. I'm looking to debug this, and I have a few questions.

First, I'm pretty sure the answer is yes, but do managed packages contribute to your total CPU time limits? And if so, to which other limits does managed package code contribute to? I can't seem to find any clear documentation of this.

Second, is there any way to track CPU time used by a specific package? This is what I see in my debug logs - this is the writeup of the limits usage of one of the packages:

Debug log

I get SOQL and DML limits, but CPU time remains at zero. I can log my own CPU time usage using the Limits.getCpuTime() command, which can help me figure out how much CPU time our internal processes are using, but I would like to identify how much time each individual managed package is responsible for using. This way we can work with the vendors of the biggest culprit(s) to hopefully resolve the issue.

  • Was this financial force? Sep 14, 2021 at 22:30

1 Answer 1


For certified managed packages, each namespace gets its own set of limits. Excepted from this separation, however, is CPU Time. Packages which are not certified share all per-transaction governors with the local namespace.

From Execution Governors and Limits:

Per-Transaction Certified Managed Package Limits

Certified managed packages—managed packages that have passed the security review for AppExchange—get their own set of limits for most per-transaction limits. Certified managed packages are developed by Salesforce ISV Partners, are installed in your org from Salesforce AppExchange, and have unique namespaces.

Here is an example that illustrates the separate certified managed package limits for DML statements. If you install a certified managed package, all the Apex code in that package gets its own 150 DML statements. These DML statements are in addition to the 150 DML statements your org’s native code can execute. This limit increase means more than 150 DML statements can execute during a single transaction if code from the managed package and your native org both execute. Similarly, the certified managed package gets its own 100-SOQL-query limit for synchronous Apex, in addition to the org’s native code limit of 100 SOQL queries.

There’s no limit on the number of certified namespaces that can be invoked in a single transaction. However, the number of operations that can be performed in each namespace must not exceed the per-transaction limits. There’s also a limit on the cumulative number of operations that can be made across namespaces in a transaction. This cumulative limit is 11 times the per-namespace limit. For example, if the per-namespace limit for SOQL queries is 100, a single transaction can perform up to 1,100 SOQL queries. In this case, the cumulative limit is 11 times the per-namespace limit of 100. These queries can be performed across an unlimited number of namespaces, as long as any one namespace doesn't have more than 100 queries. The cumulative limit doesn’t affect limits that are shared across all namespaces, such as the limit on maximum CPU time.

These cross-namespace limits apply only to namespaces in certified managed packages. Namespaces in packages that are not certified don’t have their own separate governor limits. The resources they use continue to count against the same governor limits used by your org's custom code.

  • Thanks, Adrian - this answers the first part of my question. Any idea on the second?
    – SFDC Neuf
    Sep 19, 2018 at 20:56
  • 1
    Not off the top of my head. This post is a good example of why it's often best to stick to one question per question.
    – Adrian Larson
    Sep 19, 2018 at 20:56
  • 3
    @SFDCNeuf No, CPU time can't be tracked per package, because Salesforce doesn't track it per package. In theory you could try to read the logs, but those would be guesstimates at best.
    – sfdcfox
    Sep 19, 2018 at 21:07
  • Offtopic: It's awesome to see another great contributor to SFSE with 100k+ reputation! Congrats, @AdrianLarson !!!
    – o-lexi
    Sep 19, 2018 at 22:02
  • @sfdcfox - Would it be possible for the managed package developers to track their CPU time usage if I grant them login access? Assuming they'd be willing to, of course.
    – SFDC Neuf
    Sep 20, 2018 at 16:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .