Apex runs in a multi-tenant environment. The Apex runtime engine strictly enforces limits to ensure that runaway Apex code or processes don’t monopolize shared resources. We receive requests from customers to increase the Apex code character limit in an org.
The more Apex an org holds, the more compilation is required and the more compiled output that must be stored and maintained. Compilation uses shared resources, so the limit prevents any single org from using a disproportionate share. Increases are intended for healthy orgs that are growing in a scalable way, so the added code does not disproportionately degrade the performance of your org or other orgs.
As of Summer ’18, the default Apex code character limit is 6,000,000 characters. When the limit is reached, deployments and saves that would exceed the limit are blocked.
To review the current limit and utilization in your org, from Setup, enter Apex Classes in the Quick Find box, then select Apex Classes. Review the information in the Percent of Apex Used section.
Salesforce urges you to be proactive in monitoring your org’s utilization, especially as you approach the character limit (80%–85% utilization). Be aware that the process of increasing the limit will not occur within just a few hours. Salesforce recommends that you start the process at least two weeks before you expect to hit the limit, and even earlier if remedial steps are required. Foresee reaching the limit and plan for it.
Note: As a general rule, regularly compile all Apex code in production and fix compilation failures. You must also ensure that all tests pass, and provide at least the required minimum level of code coverage.
Before you request an Apex code character limit increase, complete these audits to reduce and optimize your existing Apex code.
These items don’t count towards the code character limit.
@IsTestEnsure all the test classes are correctly annotated, including mocks (HttpCalloutMock and WebServiceMock), stubs (StubProvider), and data factories that only support tests (classes with calls to Test.startTest, Test.stopTest, Test.setMock, System.runAs). Avoid using inner classes for mocks as they cannot carry the @IsTest annotation. Test.isRunningTest() and the System.Assert methods are valid in non-test classes, so their presence alone is not an indication that an @IsTest annotation is missing.
Classes that only use the legacy testMethod keyword for individual methods—rather than the class-level @IsTest annotation—count toward the org's Apex character limit. Here's a comparison.
// Legacy test class syntax - counts toward the code limit
private class AccountServiceLegacyTest {
static testMethod void testAccountCreation() {
Account acc = new Account(Name = 'Account 1');
insert acc;
Assert.isNotNull(acc.Id, 'Account should have an ID');
}
}
// Modern test class syntax - exempt from the code limit
@IsTest
private with sharing class AccountServiceTest {
@IsTest
static void testAccountCreation() {
Account acc = new Account(Name = 'Account 1');
insert acc;
Assert.isNotNull(acc.Id, 'Account should have an ID');
}
}
To identify legacy test class syntax and calculate the character footprint, run this anonymous Apex script.
Integer totalchar = 0;
for (ApexClass a : [SELECT Id, Name, Body FROM ApexClass]) {
if (a.body.containsIgnoreCase('testmethod') && !a.body.containsIgnoreCase('@IsTest')) {
System.debug(a.Id + ' ' + a.name + ' ' + a.body.length());
totalchar = totalchar + a.body.length();
}
}
System.debug(totalchar);
For each legacy test class found, add the @IsTest annotation at the class level. We also recommend replacing any methods that still use the testmethod keyword with the @IsTest annotation.
Your org must reach at least 75% genuine code coverage. Audit your entire org for dead or commented-out code, and replace it with genuine, assertion-based tests that validate application logic and dependences. Treat the 75% coverage requirement as the minimum, not the target. Code written to artificially inflate the code coverage number is prohibited, and Salesforce Support will deny your limit increase request if test code merely executes lines without meaningful output.
Here are some examples of inflated code that may invalidate your character limit increase request if present in your org.
// Don't use arbitrary declarations
Integer i1 = 1;
Integer i2 = 1;
// ...
Integer i1000 = 1;
// Don't use repeating statements
integer i = 0;
i++;
i++;
// ...
i++;
Invalid classes: If Apex fails to compile, your request to increase Apex character limit will be denied. The isValid flag indicates whether a class is currently valid; it is set to true as long as dependent metadata remains unchanged since the last compilation. The flag is set to false if changes are made to referenced object names, fields (including superficial updates like description edits), or dependent classes. When the flag is false, recompile the class and fix any compilation failures immediately.
To recompile classes from the Salesforce UI, first open Setup. In the Quick Find box, enter and select Apex Classes to open the Apex Classes page. Click Compile all classes or Compile only invalid classes to capture the correct code utilization. The following queries can help identify invalid Apex classes.
SELECT count() FROM ApexClass WHERE isValid = false
SELECT Id, Name FROM ApexClass WHERE isValid = false
''') in place of long string + or += concatenation operations.Request an Apex code character limit increase only after you implement the best practices above.
Important: Start the limit increase process at least one week before reaching capacity. The review and implementation process requires time for Developer Support analysis. If your org is already at 90% capacity or higher, begin the request immediately to avoid blocking deployments.
To open a support case, see How to Get Support from Salesforce Help.
When you describe the case, provide this information.
isValid = true when you submit the request.Notes:
Submit a code character limit increase for the associated production org. When doing so, have as much of the current sandbox changes deployed to production as possible. After the production increase is approved, ask Support to adjust the sandbox limit up to the production value.
000382172

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.