Governor limit errors
Governor limits cap what one transaction can consume, and exceeding one throws a System.LimitException that cannot be caught with try/catch. The whole transaction rolls back. The fix is always to use less of the resource, not to handle the error.
A transaction includes everything that runs from one save: triggers, flows, validation, and any automation they set off. Limits are shared across all of it.
| Limit | Synchronous | Asynchronous | Error message |
|---|---|---|---|
| SOQL queries | 100 | 200 | Too many SOQL queries: 101 |
| Records retrieved by SOQL | 50,000 | 50,000 | Too many query rows: 50001 |
| DML statements | 150 | 150 | Too many DML statements: 151 |
| Records processed by DML | 10,000 | 10,000 | Too many DML rows: 10001 |
| CPU time | 10,000 ms | 60,000 ms | Apex CPU time limit exceeded |
| Heap size | 10 MB | 25 MB | Apex heap size too large |
| Callouts | 100 | 100 | Too many callouts: 101 |
| Future calls | 50 | 0 in batch and future, 50 in queueable | Too many future calls: 51 |
| Trigger recursion depth | 16 | 16 | Maximum trigger depth exceeded |
Source: Execution Governors and Limits, Winter ’27. Certified managed packages get their own allowance for most of these limits. CPU time and heap size are shared across the whole transaction.