Apex Exception Email
Apex Exception Email is a Salesforce Setup configuration that controls which email addresses receive notifications when an unhandled Apex exception fires in the org.
Definition
Apex Exception Email is a Salesforce Setup configuration that controls which email addresses receive notifications when an unhandled Apex exception fires in the org. By default, Salesforce sends the exception email to the user whose transaction caused the failure (or to the developer who last edited the failing class, depending on the context). The Apex Exception Email page lets administrators add additional recipients (an admin distribution list, a support team alias, a monitoring inbox) and to enable Salesforce User notifications for specific Salesforce users beyond the original trigger. The configuration sits at Setup, search for Apex Exception Email.
The feature is the simplest production monitoring surface Salesforce offers. Every unhandled exception in Apex code produces a record in Apex Job Failures and, when configured, an outbound email with the stack trace, the failing class, the user who hit it, and the input that triggered the error. Most production orgs route the exception email to a shared engineering inbox or a chat-bot integration so failures are visible in real time. The configuration is also a useful early-warning signal during deployments; a sudden uptick in exception emails after a release usually means a regression worth investigating before users start filing tickets.
How Apex Exception Email fits into Salesforce monitoring
What triggers an Apex Exception Email
Any unhandled exception thrown in Apex (DmlException, NullPointerException, QueryException, custom exceptions that escape every catch block) triggers the email. Caught exceptions do not. The triggering surface can be a trigger firing on save, a scheduled job, a Queueable, a batch class, a Future method, a Visualforce controller, an @AuraEnabled method, or an Apex REST endpoint. The email contains the exception type, the message, the stack trace, the failing class, the running user, and a snippet of the input.
Who receives the email by default
Default routing depends on the context. For synchronous user-triggered exceptions, the running user gets a Notification banner and the developer who last modified the failing class gets the email. For asynchronous jobs (scheduled, batch, future, queueable), the user who scheduled the job gets the email. The default routing rarely matches operational reality; production teams almost always add specific recipients to the Apex Exception Email page.
Adding External Email Addresses
Setup, Apex Exception Email, then click New Email under External Email Addresses. Enter the address (a distribution list, a shared monitoring inbox, a chat-bot ingestion address). External addresses do not need to be Salesforce users. This is the right path for routing failures to a team alias or a Slack-bridge inbox.
Salesforce User notifications
The same Setup page allows adding internal Salesforce Users as additional recipients. They get the exception email in addition to the default routing. Use Salesforce Users when the recipients need access to the running user's record and stack trace at the same time, since the email contains links into the org that external recipients cannot follow.
The relationship to Apex Job Failures
Every unhandled exception in async Apex (batch, scheduled, queueable, future) also writes a row to Setup, Monitor, Apex Jobs. The Apex Exception Email is the push notification; Apex Jobs is the persistent log. Together they let monitoring tools both pull (poll Apex Jobs) and push (parse the email). High-volume orgs typically build a small Flow or external integration that consumes both and forwards into their incident-response platform.
Filtering and noise control
Apex Exception Email is unfiltered. Every unhandled exception triggers a notification regardless of severity. Noisy bug clusters (one bad record producing 10,000 batch errors) can flood inboxes. The mitigation is application-level: catch and log the expected ones, propagate only the unexpected ones, and use Platform Events plus a dedicated error-handling object for everything in between. The Apex Exception Email then becomes the last line of defence, not the first.
Production monitoring patterns
Mature production teams route Apex Exception Emails into a structured ingest: a parsing rule in their email security gateway, a forwarder to PagerDuty, a Salesforce-side Email Service that lands the message into a custom error object. Each pattern uses the email as a transport but does not let humans read it directly. The volume in a large org would otherwise produce alert fatigue.
Common gotchas
Three gotchas dominate. The first is silent test exceptions: in a test context, Salesforce does not send exception emails; failures show only in the test runner. The second is timing: emails can lag the actual exception by seconds to minutes, especially in async contexts. The third is recipient quotas: very large orgs occasionally hit the daily email send limit if exception volume spikes, in which case some emails never arrive. Plan monitoring on durable signals (Apex Jobs, Event Monitoring), not solely on email.
How to configure Apex Exception Email
Setup takes about five minutes. The longer-term work is making sure the recipient inbox is monitored and the application code surfaces enough context for whoever opens the email to act on it.
- Open Apex Exception Email
Setup, then search for Apex Exception Email. The page shows the current list of Salesforce User and External Email Address recipients.
- Add an External Email Address
Under External Email Addresses, click New Email. Add the team distribution list or monitoring inbox. Save.
- Optionally add Salesforce User recipients
Under Salesforce Users, search and add internal users who should receive every exception email.
- Trigger a test exception
Run an anonymous Apex block that throws on purpose (e.g., Integer.valueOf('not-a-number')). Confirm the email arrives at every configured recipient within a few minutes.
- Integrate with a monitoring tool
For production, forward the inbox to PagerDuty, Slack, or a Salesforce Email Service. Plain inbox monitoring rarely scales past a small team.
- Apex Exception Email is unfiltered. High-volume bugs can flood the inbox and produce alert fatigue. Use application-level error handling to suppress expected exceptions.
- Emails can lag the underlying exception by seconds to minutes, especially in async contexts. Do not rely on email latency for incident response.
- Test exceptions do not send email. Failures only show in the test runner. Production monitoring cannot be validated through Apex tests alone.
- Very large orgs can hit the daily email send limit if exception volume spikes. Build a durable pull-based monitoring layer alongside email.
Trust & references
Cross-checked against the following references.
- Apex Exception EmailSalesforce Help
- Monitor Apex JobsSalesforce Help
Straight from the source - Salesforce's reference material on Apex Exception Email.
- Apex Exception HandlingApex Developer Guide
Hands-on resources to go deeper on Apex Exception Email.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Governor Limit in the context of Apex Exception Email?
Q2. What is required before deploying Apex Exception Email-related code to production?
Q3. Where would a developer typically work with Apex Exception Email?
Discussion
Loading discussion…