Fix "Apex CPU Time Limit Exceeded" in Salesforce

By Prit Sakhvala, Salesforce Developer · Updated July 2026

What counts toward CPU time — and what doesn't

This is why the error is confusing: the visible slow part of a transaction (a big query) is often free, while an innocent-looking loop is what burns the budget.

The usual suspects

1. Loops over loops. Nested iteration over related records (O(n²) comparisons) is the single most common cause. 200 trigger records × 1,000 comparisons each is 200,000 iterations before you've done anything useful.
2. Trigger recursion. An update trigger that performs updates re-fires automation. Two or three re-entries multiply all trigger CPU.
3. Non-bulkified helper methods called once per record instead of once per batch.
4. Record-triggered Flows stacking on triggers. Each Flow element costs CPU; a loop inside a Flow over hundreds of records adds up fast.
5. Heavy string/JSON processing — serializing large payloads, regex over long text, building huge strings by concatenation.
6. Managed package automation you can't see — but which absolutely bills to your transaction's CPU.

Finding the hotspot in the debug log

Every log line carries a nanosecond elapsed counter, e.g. (5348351). The manual method:

2,830,000,000 − 120,000,000 = 2.71 s wall time in that trigger. Do this for every CODE_UNIT pair, rank them, then drill into the worst one. Also check the summary at the end of the log:

Doing this by hand across a 50,000-line log is exactly the tedium a debug log analyzer removes. ForceLens's Performance tab ranks code units by time consumed, its Timeline shows where the transaction's time physically went, and the Limits tab shows CPU consumption against the 10 s budget — parsed from the same log, in one click.

Fixes that actually work

• Bulkify. Query once before the loop; process collections; never call a per-record helper in a loop. Replace nested loops with Map<Id, SObject> lookups — this alone turns O(n²) into O(n).
• Stop recursion. Use a static guard variable or, better, restructure so triggers don't update their own object unnecessarily.
• Move work async. Queueables, future methods, and batch Apex get a 60 s CPU budget and run outside the user's save. Anything not needed synchronously — roll-ups, integrations, enrichment — belongs there.
• Tune Flows. Consolidate multiple record-triggered Flows per object, avoid loops over large collections inside Flows, and push heavy logic to (bulkified) Apex where appropriate.
• Audit managed packages. If a package's automation dominates the log, check its settings for toggles, or scope which record changes invoke it.
• Cache expensive computation. Static variables survive for the transaction — compute once, reuse.

Frequently asked questions