Practice
Salesforce is one of the first and most widely used multi-tenant SaaS platforms. Enforcing controlled resource usage is fundamental to any multi-tenant system, and Salesforce does it through governor limits. That is what makes the platform work — and it is also what makes it unusually hard to debug.
Managed package · LaaS
Component-based logging you can tune at runtime, at org, profile, or user level. Built so that when something breaks in production, the trace already exists — rather than asking the customer for steps to reproduce.
Salesforce runs many customers on shared infrastructure, so it caps what any one tenant can consume — CPU time, heap, query counts. Those governor limits are why the platform scales. They are also why the usual debugging habits do not transfer.
The platform's built-in logging reflects that tension. It produces a great deal of internal execution detail while being poorly targeted at the Apex you actually wrote. It has to be switched on for a window of time rather than left running, so it tends to be off precisely when the interesting thing happens. And it is not component-aware, so it cannot be narrowed to the part of the system under suspicion.
For managed packages the gap is wider still: reading the logs at all can require Salesforce Support to be involved, which puts a support queue between a developer and the answer.
LaaS is a deliberately modest response to that. It does not replace platform logging. It gives developers an out-of-the-box framework for the cases the platform handles badly, at a cost in CPU, heap, and governor limits that you should spend knowingly.
There are no free lunches. Logging consumes the same limited resources as the code being logged, which is why LaaS is tunable rather than always-on.
Whether it is LaaS or a Salesforce problem of your own, we are happy to talk it through.
Get in touch