Understanding Execution Governors and Limits

Because Apex runs in a multitenant environment, the Apex runtime engine strictly enforces a number of limits to ensure that runaway Apex does not monopolize shared resources. These limits, or governors, track and enforce the statistics outlined in the following table. If some Apex code ever exceeds a limit, the associated governor issues a runtime exception that cannot be handled.

Governor limits apply to an entire organization, as well as to specific namespaces. For example, if you install a managed package created by a salesforce.com ISV Partner from Force.com AppExchange, the components in the package belong to a namespace unique from other components in your organization. Consequently, any Apex code in that package can issue up to 150 DML statements while executing. In addition, any Apex code that is native to your organization can also issue up to 150 DML statements, meaning more than 150 DML statements might execute during a single request if code from the managed package and your native organization both execute. Conversely, if you install a package from AppExchange that is not created by a salesforce.com ISV Partner, the code from that package does not have its own separate governor limit count. Any resources it uses counts against the total for your organization. Cumulative resource messages and warning emails are also generated based on managed package namespaces as well. For more information on salesforce.com ISV Partner packages, see salesforce.com Partner Programs.

Description	Limit
Total number of SOQL queries issued¹	100
Total number of SOQL queries issued for Batch Apex and future methods¹	200
Total number of records retrieved by SOQL queries	50,000
Total number of records retrieved by `Database.getQueryLocator`	10,000
Total number of SOSL queries issued	20
Total number of records retrieved by a single SOSL query	200
Total number of DML statements issued²	150
Total number of records processed as a result of DML statements, `Approval.process`, or `database.emptyRecycleBin`	10,000
Total number of executed code statements	200,000
Total number of executed code statements for Batch Apex and future methods	1,000,000
Total heap size³	6 MB
Total heap size for Batch Apex and future methods	12 MB
Total stack depth for any Apex invocation that recursively fires triggers due to `insert`, `update`, or `delete` statements⁴	16
For loop list batch size	200
Total number of callouts (HTTP requests or Web services calls) in a request	10
Maximum timeout for all callouts (HTTP requests or Web services calls) in a request	120 seconds
Default timeout of callouts (HTTP requests or Web services calls) in a request	10 seconds
Total number of methods with the `future` annotation allowed per Apex invocation⁵	10
Maximum size of callout request or response (HTTP request or Web services call)⁶	3 MB
Total number of `sendEmail` methods allowed	10
Total number of describes allowed⁷	100
Total number of classes that can be scheduled concurrently	25
Total number of test classes that can be queued per a 24-hour period⁸	The greater of 500 or 10 multiplied by the number of test classes in the organization

¹ In a SOQL query with parent-child relationship sub-queries, each parent-child relationship counts as an additional query. These types of queries have a limit of three times the number for top-level queries. The row counts from these relationship queries contribute to the row counts of the overall code execution. In addition to static SOQL statements, calls to the following methods count against the number of SOQL statements issued in a request.

Database.countQuery
Database.getQueryLocator
Database.query

² Calls to the following methods count against the number of DML queries issued in a request.

Approval.process
Database.convertLead
Database.emptyRecycleBin
Database.rollback
Database.setSavePoint
delete and Database.delete
insert and Database.insert
merge
undelete and Database.undelete
update and Database.update
upsert and Database.upsert
System.runAs

³ Email services heap size is 36 MB.

⁴ Recursive Apex that does not fire any triggers with insert, update, or delete statements exists in a single invocation, with a single stack. Conversely, recursive Apex that fires a trigger spawns the trigger in a new Apex invocation, separate from the invocation of the code that caused it to fire. Because spawning a new invocation of Apex is a more expensive operation than a recursive call in a single invocation, there are tighter restrictions on the stack depth of these types of recursive calls.

⁵ Salesforce also imposes a limit on the number of future method invocations: 200 method calls per full Salesforce user license or Force.com App Subscription user license, per 24 hours. This is an organization-wide limit. Chatter Only, Chatter customer users, Customer Portal User, and partner portal User licenses aren’t included in this limit calculation. For example, suppose your organization has three full Salesforce licenses, two Force.com App Subscription licenses, and 100 Customer Portal User licenses. Your entire organization is limited to only 1,000 method calls every 24 hours, calculated as 200 x (3+2), not 200 x (3+2+100).

⁶ The HTTP request and response sizes count towards the total heap size.

⁷ Describes include the following methods and objects.

ChildRelationship objects
RecordTypeInfo objects
PicklistEntry objects
fields calls
fieldsets calls

⁸ This limit applies to tests running asynchronously. This includes tests started through the Salesforce user interface including the Developer Console or by inserting ApexTestQueueItem objects using SOAP API.

Limits apply individually to each testMethod.

Use the Limits methods to determine the code execution limits for your code while it is running. For example, you can use the getDMLStatements method to determine the number of DML statements that have already been called by your program, or the getLimitDMLStatements method to determine the total number of DML statements available to your code.

For best performance, SOQL queries must be selective, particularly for queries inside of triggers. To avoid long execution times, non-selective SOQL queries may be terminated by the system. Developers will receive an error message when a non-selective query in a trigger executes against an object that contains more than 100,000 records. To avoid this error, ensure that the query is selective. See More Efficient SOQL Queries.

For Apex saved using Salesforce.com API version 20.0 or earlier, if an API call causes a trigger to fire, the batch of 200 records to process is further split into batches of 100 records. For Apex saved using Salesforce.com API version 21.0 and later, no further splits of API batches occur. Note that static variable values are reset between batches, but governor limits are not. Do not use static variables to track state information between batches.

In addition to the execution governor limits, Apex has the following limits.

The maximum number of characters for a class is 1 million.
The maximum number of characters for a trigger is 1 million.
The maximum amount of code used by all Apex code in an organization is 3 MB.
Note
This limit does not apply to certified managed packages installed from AppExchange, (that is, an app that has been marked AppExchange Certified). The code in those types of packages belong to a namespace unique from the code in your organization. For more information on AppExchange Certified packages, see the Force.com AppExchange online help.
This limit also does not apply to any code included in a class defined with the @isTest annotation.
There is a limit on the method size. Large methods that exceed the allowed limit cause an exception to be thrown during the execution of your code. Like in Java, the method size limit in Apex is 65,535 bytecode instructions in compiled form.
If a SOQL query runs more than 120 seconds, the request can be canceled by Salesforce.
Each Apex request is limited to 10 minutes of execution.
A callout request is limited to a maximum of 20 simultaneous requests to URLs with the same host. The host is defined by the unique subdomain for the URL, for example, www.mysite.com and extra.mysite.com are two different hosts. This limit is calculated across all organizations that access the same host. If this limit is exceeded, a CalloutException will be thrown.
The maximum number of records that an event report returns for a user who is not a system administrator is 20,000, for system administrators, 100,000.
Each organization is allowed 10 synchronous concurrent requests for long-running requests that last longer than 5 seconds. If additional requests are made while the 10 long-running requests are still running, they are denied.
A user can have up to 50 query cursors open at a time. For example, if 50 cursors are open and a client application still logged in as the same user attempts to open a new one, the oldest of the 50 cursors is released. Note that this limit is different for the batch Apexstart method, which can have up to five query cursors open at a time per user. The other batch Apex methods have the higher limit of 50 cursors.
Cursor limits for different Force.com features are tracked separately. For example, you can have 50 Apex query cursors, 50 batch cursors, and 50 Visualforce cursors open at the same time.
In a single transaction, you can only reference 10 unique namespaces. For example, suppose you have an object that executes a class in a managed package when the object is updated. Then that class updates a second object, which in turn executes a different class in a different package. Even though the second package wasn’t accessed directly by the first, because it occurs in the same transaction, it’s included in the number of namespaces being accessed in a single transaction.
Any deployment of Apex is limited to 5,000 code units of classes and triggers.
If you use the Data.com Clean product and its automated jobs, and you have set up Apex triggers with SOQL queries to run when account, contact, or lead records, the queries may interfere with Clean jobs for those objects. Your Apex triggers (combined) should not exceed 200 SOQL queries per batch. If they do, your Clean job for that object will fail. In addition, if your triggers call future methods, they will be subject to a limit of 10 future calls per batch.

Email Limits

Inbound Email Limits

Email Services: Maximum Number of Email Messages Processed (Includes limit for On-Demand Email-to-Case)	Number of user licenses multiplied by Number of user licenses multiplied by 1,000, up to a daily maximum of 1,000,000
Email Services: Maximum Size of Email Message (Body and Attachments)	10 MB¹
On-Demand Email-to-Case: Maximum Email Attachment Size	10 MB
On-Demand Email-to-Case: Maximum Number of Email Messages Processed (Counts toward limit for Email Services)	Number of user licenses multiplied by 1,000, up to a daily maximum of 1,000,000

¹ The maximum size of email messages for Email Services varies depending on language and character set.

When defining email services, note the following:

An email service only processes messages it receives at one of its addresses.
Salesforce limits the total number of messages that all email services combined, including On-Demand Email-to-Case, can process daily. Messages that exceed this limit are bounced, discarded, or queued for processing the next day, depending on how you configure the failure response settings for each email service. Salesforce calculates the limit by multiplying the number of user licenses by 1,000, up to a daily maximum of 1,000,000. For example, if you have ten licenses, your organization can process up to 10,000 email messages a day.
Email service addresses that you create in your sandbox cannot be copied to your production organization.
For each email service, you can tell Salesforce to send error email messages to a specified address instead of the sender's email address.
Email services rejects email messages and notifies the sender if the email (combined body text, body HTML and attachments) exceeds approximately 10 MB (varies depending on language and character set).

Outbound Email: Limits for Single and Mass Email Sent Using Apex

You can send single emails to a maximum of 1,000 external email addresses per day based on Greenwich Mean Time (GMT). Single emails sent using the application don't count towards this limit.

You can send mass email to a total of 1,000 external email addresses per day per organization based on Greenwich Mean Time (GMT). The maximum number of external addresses you can include in each mass email depends on the Edition of Salesforce you are using:

Edition	Address Limit per Mass Email
Professional	250
Enterprise Edition	500
Unlimited Edition	1,000

Note

Note the following about email limits:

The single and mass email limits don't take unique addresses into account. For example, if you have johndoe@example.com in your email 10 times, that counts as 10 against the limit.
You can send an unlimited amount of email to your internal users. These limits also apply to emails sent using the API and Apex.
In Developer Edition organizations and organizations evaluating Salesforce during a trial period, your organization can send mass email to no more than 10 external email addresses per day. This lower limit does not apply if your organization was created before the Winter '12 release and already had mass email enabled with a higher limit.

Batch Apex Governor Limits

Keep in mind the following governor limits for batch Apex:

Up to five queued or active batch jobs are allowed for Apex.
A user can have up to 50 query cursors open at a time. For example, if 50 cursors are open and a client application still logged in as the same user attempts to open a new one, the oldest of the 50 cursors is released. Note that this limit is different for the batch Apexstart method, which can have up to five query cursors open at a time per user. The other batch Apex methods have the higher limit of 50 cursors.
Cursor limits for different Force.com features are tracked separately. For example, you can have 50 Apex query cursors, 50 batch cursors, and 50 Visualforce cursors open at the same time.
A maximum of 50 million records can be returned in the Database.QueryLocator object. If more than 50 million records are returned, the batch job is immediately terminated and marked as Failed.
If the start method returns a QueryLocator, the optional scope parameter of Database.executeBatch can have a maximum value of 2,000. If set to a higher value, Salesforce chunks the records returned by the QueryLocator into smaller batches of up to 2,000 records. If the start method returns an iterable, the scope parameter value has no upper limit; however, if you use a very high number, you may run into other limits.
If no size is specified with the optional scope parameter of Database.executeBatch, Salesforce chunks the records returned by the start method into batches of 200, and then passes each batch to the execute method. Apex governor limits are reset for each execution of execute.
The start, execute, and finish methods can implement up to 10 callouts each.
Batch executions are limited to 10 callouts per method execution.
The maximum number of batch executions is 250,000 per 24 hours.
Only one batch Apex job's start method can run at a time in an organization. Batch jobs that haven’t started yet remain in the queue until they're started. Note that this limit doesn’t cause any batch job to fail and execute methods of batch Apex jobs still run in parallel if more than one job is running.