Fix Guides

Fix Apex CPU Timeout and Heap Size Too Large Errors in Salesforce

Step-by-step fix guide with AI-powered diagnosis from BuildForce.

The Error: "System.LimitException: Apex CPU time limit exceeded"

This fires when synchronous Apex consumes more than 10,000ms of actual processor compute in a single transaction (60,000ms for async Apex — Queueable, Batch, Future). CPU time excludes time spent waiting on a SOQL query, a DML statement, or a callout to return — it only counts the work your code itself does. A transaction that's slow but shows low CPU time in the debug log has a database or network bottleneck, not a CPU-limit problem, and bulkifying loops won't fix that case.

The Error: "System.LimitException: Apex heap size too large"

This fires when the memory your variables, collections, and query results occupy at one moment exceeds 6MB for synchronous Apex (12MB for async). Unlike CPU time, heap size has nothing to do with how much compute your code does — a single List holding 50,000 wide Case records can exceed the heap ceiling while barely touching the CPU budget. This is the more common failure on Case merge, escalation, and nightly SLA-recalculation jobs, where the object carries long text fields and related attachments.

Common Causes

• SOQL or DML inside a loop — A query or a record.save() call placed inside a for-loop runs once per iteration instead of once per transaction. At 200 Cases that's 200 queries; each one also holds its result set in heap until the transaction ends.
• Non-selective queries on Case and related objects — SELECT Id, Subject, Description FROM Case with no indexed WHERE clause returns every column you asked for, for every row that matches — often the full object. Filtering late (after the query, in Apex) instead of in the SOQL WHERE clause means the unfiltered result set sits in heap first.
• Recursive trigger chains — A Case update that fires a trigger, which updates a related Case, which fires the trigger again, re-runs the same expensive logic multiple times inside one transaction — multiplying both the compute and the memory footprint on every pass.
• Large data volume with no chunking — A nightly job that recalculates SLA milestones, re-scores every open Case, or merges duplicate Cases across the full object with no LIMIT or batching processes the entire table in one transaction instead of in governor-limit-sized chunks.
• Attachments and long text fields held in memory — Case objects carry Description, email body text, and related Attachment or ContentVersion records. Querying those fields for a large result set — instead of paging or querying only the records that changed — is a fast way to exceed the 6MB synchronous heap ceiling.

How to Fix It — Step by Step

1. 1. Pull the debug log and read Cumulative Limit Usage. Setup → Debug Logs, reproduce the failure, and open the CUMULATIVE LIMIT USAGE section of the resulting log. It reports CPU time and heap size consumed at the point of failure — confirm which limit actually tripped before changing code.
2. 2. Bulkify every SOQL query and DML statement. Move queries and record.save() calls outside of loops. Query once into a List or Map before the loop, operate on the in-memory collection, then issue one bulk DML call (update, insert) after the loop completes.
3. 3. Make every query selective. Add a WHERE clause on an indexed field (Id, a custom External ID field, an indexed lookup) and query only the columns the transaction actually uses. Filter in SOQL, not in an Apex loop after the fact — an unfiltered result set has already consumed heap by the time Apex code sees it.
4. 4. Add a recursion guard. Use a static Set<Id> or static Boolean in a helper class to track which Case Ids have already run through the expensive logic in the current transaction, so a trigger chain doesn't recompute the same work on every save.
5. 5. Move large-data-volume work to Queueable or Batch Apex. Batch Apex processes records in configurable chunks (200 by default) across separate transactions, each with its own fresh 12MB heap and 60,000ms CPU budget. Anything touching more Cases than a single save should run there, not synchronously.
6. 6. Release memory you no longer need. Set large collections to null once they're no longer needed within the transaction, rather than holding every intermediate result until the method returns. This matters most in loops that build up multiple large Lists or Maps in sequence.
7. 7. Re-test at 200+ records before calling it fixed. Run the fix against a bulk data set, not a single Case. Both CPU and heap bugs are invisible at small scale and only appear once the collection sizes and iteration counts reflect production volume.

Example: Bulkifying a Case Escalation Loop

// BAD — query and update inside the loop: N queries, N DML statements,
// and every result set held in heap until the transaction ends
for (Case c : triggerNewCases) {
    Case fullCase = [SELECT Id, Description, Entitlement.Name
                     FROM Case WHERE Id = :c.Id]; // 1 query per record
    fullCase.Status = 'Escalated';
    update fullCase;                              // 1 DML per record
}

// GOOD — one selective query, one bulk DML call
Set<Id> caseIds = new Map<Id, Case>(triggerNewCases).keySet();
List<Case> casesToEscalate = [
    SELECT Id, Status FROM Case
    WHERE Id IN :caseIds AND Status != 'Escalated'
];
for (Case c : casesToEscalate) {
    c.Status = 'Escalated';
}
update casesToEscalate;

Prevention

• Bulk-test every Case trigger and batch job at 200+ records — the Salesforce bulk standard — before it reaches production, not after a real import or escalation run trips the limit.
• Read Cumulative Limit Usage on every debug log, not just the ones that already failed, to catch a class approaching the ceiling before it crosses it.
• Chunk large-data-volume jobs into Batch Apex with a scope size (200 default) sized to the actual row width — wide Case records with attachments may need a smaller scope than a narrow lookup object.
• Review new Apex for loop-embedded SOQL/DML and non-selective queries before merge, not after a governor-limit failure surfaces it in production.

This Error Is a Symptom, Not the Root Cause

A query-in-a-loop or non-selective SOQL pattern that shipped in one Case trigger is a style the same class, or the same copied boilerplate, likely repeats elsewhere in the org. Run BuildForce's free health check to find every instance of this pattern in your org, not just the one that just failed — then connect your org so BuildForce can scan every Apex class for CPU and heap risk before the next bulk case load or SLA recalculation finds the next one.

How BuildForce Prevents This

• Continuous Apex health checks — surface loop-embedded SOQL/DML, non-selective queries, and recursion risk across every class, not just the one in the latest error log.
• Deep dive: fixing CPU time limit exceeded — full algorithmic-complexity walkthrough (nested loops, regex in loops, string concatenation) if CPU time, not heap, is the limit you're hitting.
• AI consultant for Apex debugging — paste a debug log or stack trace and get a remediation plan scoped to your org's actual data model.

FAQ