Skip to content

Observability

Standards for seeing what the org is doing in production: how every automation layer logs, how platform activity is monitored, and where both end up.

An Observability Platform Is Required

Every company running Salesforce must operate an observability platform, and the org must not be the only place its logs live. Logs held only in the org are limited by org storage, invisible to the teams who watch the rest of the engineering stack, and unavailable when the org itself is the thing under investigation. The observability platform is where production errors raise alerts, where application failures are correlated with the deployments that caused them, and where logs are retained for as long as policy requires.

It is also where integrations are troubleshot. A failed callout, a rejected inbound request, or a message that never arrived involves at least two systems, and the org's own logs show only one side of the conversation. An observability platform that receives logs from the org and from the systems it integrates with is the only place a failure can be followed end to end, from the request that left one system to the error that came back from the other. Log the integration traffic itself (request and response bodies, status codes, and correlation identifiers) through the logging framework, with data masking applied, so that the trail exists before it is needed.

Logging in the Org

Every automation layer logs through one centralised, Platform-Event-backed logging framework rather than System.debug or console.log. Nebula Logger is the reference implementation, and it covers every layer: Apex, Flow, Lightning Web Components, Aura, and OmniStudio.

  • Log entries publish as platform events. Nebula Logger's LogEntryEvent__e is a Publish Immediately event, so entries are published even when the transaction that wrote them rolls back; keep the default event-bus save method so failures are recorded rather than lost with the transaction.
  • Log levels are set through the LoggerSettings__c hierarchy custom setting, so they can be tuned for the whole org, a profile, or a single user without a deployment. Production runs at a level that records errors and warnings; verbose levels are switched on for a specific user while diagnosing a problem, then switched off.
  • Data masking is enabled (IsDataMaskingEnabled__c in LoggerSettings__c), and the org maintains data mask rules (LogEntryDataMaskRule__mdt) for its own sensitive data patterns, in addition to the rules that ship with the package. Mask rules apply to log messages, record JSON, and HTTP request and response bodies before anything is stored.
  • Logging code respects platform event limits; see Platform Event Limits below.

Platform Event Limits

The platform event limits that matter for logging

Every custom platform event is subject to governor limits and allocations, and a logging framework built on platform events is no exception. The limits that matter most for logging are shared by the whole org:

  • Per transaction: each Publish Immediately EventBus.publish() call counts against a limit of 150 per transaction. Add log entries inside loops if needed, but save them once, outside the loop.
  • Per hour, across the org: every platform event published in the org, from Apex, Flow, or any API, draws on one shared hourly publishing allocation. When it is used up, further publish calls fail with a limit-exceeded error, and the events are not queued for later.
  • Per day, for external subscribers: events delivered to subscribers outside the org, through the Pub/Sub API, CometD, or event relays, draw on a separate daily delivery allocation. Streaming log events to an observability platform consumes it.

The hourly allocation is the dangerous one. It is shared by every platform event in the org, not only log entries, so a logging framework that publishes too much does not just lose its own logs: it can stop the org publishing the business events that integrations and automation depend on, until the allocation recovers.

Configure the logging framework to publish only essential events. In production, set LoggerSettings__c to a level that records errors and warnings, raise it only for a named user while diagnosing a problem, and never leave verbose logging switched on for the whole org. Monitor platform event usage on the observability platform alongside the logs themselves, so that an approaching limit raises an alert before it becomes an outage.

Logging Levels by Environment

Logging levels are set by configuration in each org, and never by code that checks which kind of org it is running in.

Code can detect the kind of org it runs in and log more outside production. Do not do this. The logging level can differ between orgs, but only through the configuration of each org, for example the records of Nebula Logger's LoggerSettings__c, a hierarchy custom setting that can set a level for the org, a profile, or a single user, and that an administrator sets and can see in Setup.

Code checks the kind of org for one purpose only: to decide whether an automation runs at all (Automation: Environment Check). Code that checks the kind of org to change how it logs is risky for several reasons:

  • Sandboxes are not safe environments. A full sandbox, or a partial copy sandbox, that has not been sanitised holds live production data. Verbose logs and debug output there carry exactly the same exposure as they would in production, so "it's only a sandbox" is not a reason to log more.
  • Sandbox access is usually wider than production access. Developers, testers, contractors, and partners often have access to sandboxes they would never be given in production, so the same log entry is readable by more people in a sandbox than in production.
  • The code that was tested is not the code that runs. A branch that behaves one way outside production and another way in production means production executes a path that no sandbox ever exercised. The Apex on the production-only branch may never have been run by any test: tests in a sandbox follow the sandbox branch, and overall code coverage can pass while the lines that only run in production go untested.
  • Environment detection is fragile. Checks on org IDs, domain names, or sandbox names break on refresh, clone, and domain changes, and a check that misfires can switch verbose logging on in production without anyone noticing.
  • Behaviour hidden in code escapes review. Configuration in LoggerSettings__c is visible and auditable in each org; a flag buried in code is visible only to someone reading that code.

Logging settings, including data masking, are the same in every environment unless there is a specific, recorded reason to change them. Treat logs from any sandbox that contains production data with the same data classification as production logs.

Rules that keep debug output out of code, and treat it as a security control rather than a style preference, live with the code they govern: see Apex: Debug Output and Error Disclosure and JavaScript: Console and Debugger Statements. Automation-specific logging rules, such as wiring every Flow fault path to the logging framework, live in the Automation Framework.

Sources:

Platform Monitoring with Salesforce Shield

Application logs show what the org's own code did. Salesforce Shield shows what users, integrations, and agents did to the org. Shield has four components, and all four are part of the standard:

  • Event Monitoring records user and agent activity across the org and can block risky behaviour.
  • Platform Encryption encrypts data at rest, with keys under the customer's control.
  • Field Audit Trail keeps field-level change history for compliance and forensic investigation.
  • Data Detect scans records to find PII and other sensitive data, including data sitting in fields that were never classified as sensitive.

Event Monitoring is the part that feeds observability. It answers the questions an investigation starts with: who logged in, from where, what they exported, and who accessed a given record or file.

  • Event Log Files are downloadable hourly or daily files covering many event types. They are an ingestion source, not a system of record: hourly files arrive hours after the event, and retention is limited, so they are forwarded to the observability platform rather than read in place.
  • Event Log Objects hold event data in queryable objects for SOQL, dashboards, and export.
  • Real-Time Event Monitoring publishes events as they happen, for streaming to the observability platform and for storage in the org.
  • Transaction Security policies act on real-time events as they occur: blocking the action, requiring multi-factor authentication, or sending a notification.
  • The Event Monitoring Analytics app gives a built-in view of event data inside Salesforce.

Event Monitoring data is forwarded to the observability platform through a dedicated integration user and permission set, and retained there according to the company's records-retention schedule. Audit events (logins, record and file access, exports) belong in the same platform as application logs, so that a single investigation can follow a user, an integration, or an agent across both.

Sources:

Getting Logs Off-Platform

Do not let logs stop at the org. Connect the logging framework and Event Monitoring to the observability platform the rest of the engineering stack already uses: platform-event log entries can be streamed off-platform through the Pub/Sub API, CometD, or existing middleware, and the major platforms ship supported Salesforce integrations. Forwarding runtime logs to the same place that receives pipeline telemetry (see Governance at Scale and Measuring Maturity) gives one console for the whole delivery lifecycle.

{N} rules govern the connection:

  • Log payloads never contain PII, PHI, credentials, or session material. Once an event streams off-platform it is outside Salesforce's access controls, so the data classification of the log content sets the boundary, not the convenience of the integration.
  • Streaming log events outside the org is an integration like any other: it goes through the same security review as every outbound connection, with a dedicated integration user and least-privilege access to the event channel.

Observability Platforms

The standard requires an observability platform; it does not mandate which one. The first two entries are not observability platforms themselves but the sources inside Salesforce that feed one: Nebula Logger is the logging framework for the org's own code, and Shield Event Monitoring records what users, integrations, and agents do in the org. Each of the other platforms has a vendor-supported Salesforce integration:

Platform Salesforce integration AppExchange package
Nebula Logger Runs inside the org; see Nebula Logger below No listing; its GitHub repository publishes unlocked and managed packages that admins install directly
Shield Event Monitoring Built into Salesforce, for an additional cost; see Shield Event Monitoring below Not applicable; part of Salesforce
Datadog Salesforce integration Datadog for Salesforce Service Cloud (creates Service Cloud incidents from Datadog monitors; it does not collect org logs)
Splunk Splunk Add-on for Salesforce and Splunk Add-on for Salesforce Streaming API No
Elastic Salesforce integration No
New Relic Salesforce Event Logs integration No
Dynatrace Salesforce Insights No
Sumo Logic Salesforce Source and Sumo Logic App for Salesforce No
Microsoft Sentinel Salesforce Service Cloud solution No
Google Security Operations Salesforce log collection No
IBM QRadar Salesforce Security DSM No
Exabeam Salesforce Cloud Collector No
Rapid7 InsightIDR Salesforce event source No
Coralogix Salesforce integration No
Logz.io Salesforce log shipping No
Grafana Salesforce data source (queries Salesforce data for dashboards; it does not ship logs) No

AppExchange status was checked in September 2026 against vendor-published listings. Every integration above works without an AppExchange package: they read Salesforce through its APIs, so nothing is installed in the org.

Sources:

Deeper Dive: Nebula Logger, Shield Event Monitoring, Datadog, and Splunk

TODO(David)

Expand each platform below: capabilities worth standardising on, FedRAMP authorisation status and level (verify against the FedRAMP Marketplace), and Salesforce-specific features.

These four get closer attention: Nebula Logger and Shield Event Monitoring because together they produce the org's log and event data, and Datadog and Splunk because they are the platforms Salesforce teams most often send that data to.

Nebula Logger

What Nebula Logger is, and how it is installed and configured

Nebula Logger is an open-source logging framework that runs inside the org. It is the source of application logs; the observability platform is where they end up.

  • Installation: Nebula Logger has no AppExchange listing. Its GitHub repository publishes two packages, each with install links for sandboxes and production and an sf package install command, so an admin can install either one from a browser: an unlocked package with no namespace, which the author recommends, and a managed package in the Nebula namespace. The metadata is the same in both, but some features, including the plugin framework, are available only in the unlocked package. In package-based development, declare Nebula Logger as a dependency of the org's packages so it is always installed wherever they are.
  • Coverage: Apex (classes, triggers, and anonymous Apex), Flow, Lightning Web Components, Aura, and OmniStudio (OmniScripts and Integration Procedures), all writing to the same log records.
  • Save methods: the default, EVENT_BUS, publishes LogEntryEvent__e, a high-volume Publish Immediately platform event, so entries survive a rollback. QUEUEABLE, REST, and SYNCHRONOUS_DML are also available; with SYNCHRONOUS_DML, an exception rolls back the log entries along with everything else.
  • Configuration: LoggerSettings__c is a hierarchy custom setting (org, profile, and user) controlling logging level, save method, and data masking; LoggerParameter__mdt holds org-wide feature flags.
  • Data masking: LogEntryDataMaskRule__mdt rules apply regular expressions to messages, record JSON, and HTTP request and response bodies. The package ships rules for card numbers and US Social Security numbers; each org adds rules for its own sensitive data.
  • Getting off-platform: because entries are published as platform events, an observability platform that subscribes to custom platform events through the Pub/Sub API can receive them as they happen.

Nebula Logger Plugins

The plugins that the repository publishes

Nebula Logger has a plugin framework, available in the unlocked package only, that runs Apex or Flow automation on its log records. The repository publishes these plugins:

  • Async Failure Additions adds logging for asynchronous failures, including Flow error events.
  • Big Object Archiving archives logging data to a big object, LogEntryArchive__b.
  • Log Retention Rules sets the retention date of log records through configurable rules in custom metadata.
  • Slack posts logs at or above a configurable level to a Slack channel.

Other tools can log through Nebula Logger too. Apex Rollup, James Simone's open-source rollup framework, publishes its own Nebula Logger plugin, installed as a separate package. If the org uses Apex Rollup, install the plugin so that rollup operations log through Nebula Logger into the same log records as everything else, rather than to Apex debug logs.

TODO

Log retention and purge settings, and how log records relate to Event Monitoring data.

Shield Event Monitoring

What Event Monitoring records, and the ways to get the data

Event Monitoring is Salesforce's own record of activity in the org: logins, API calls, report exports, page views, Apex executions, and many other event types. It is available for an additional cost from Salesforce, either as part of Salesforce Shield or on its own. Some event types are available in every org without Shield: Login, Logout, API Total Usage, and Apex Unexpected Exception among them, with one day of retention. Every other event type requires Shield or the Event Monitoring add-on, which also retains event data for a year by default and delivers it hourly as well as daily. The full list of event types is in Salesforce's EventLogFile Supported Event Types reference.

There are two ways to get the data: download it after the fact, or subscribe to it as it happens.

  • Download: Event Log Files. Event data is written to Event Log Files, one file per event type per period, retrieved through the REST API (the EventLogFile object) or browsed in Setup. Hourly files arrive a few hours after the events they describe and daily files the next day, so this is the route for investigation and analysis, not for alerting. Event Log Files are an ingestion source rather than a system of record: forward them to the observability platform and keep them there.
  • Query: Event Log Objects. The same event data is also available in queryable objects, so it can be read with SOQL, used in dashboards, or exported.
  • Subscribe: Real-Time Event Monitoring. Salesforce publishes standard real-time event types (such as login, API, and report events) as they happen. Subscribe to them through the Pub/Sub API to stream them to the observability platform, and store the ones worth keeping in the org through Event Manager.
  • Act: Transaction Security. Transaction Security policies run against real-time events and can block an action, require multi-factor authentication, or send a notification, so Event Monitoring can prevent a risky action as well as record it.

TODO

Which event types matter most for security and troubleshooting, retention settings (Event Monitoring Settings or EventSettings metadata), and the Event Monitoring Analytics app.

Datadog

  • Salesforce integration: Datadog's Salesforce integration collects Event Log Files, the Real-Time Event Monitoring stream, and custom platform events through the Pub/Sub API, which covers both Shield event data and Nebula Logger's LogEntryEvent__e.
  • AppExchange: Datadog is the only platform in the table with a vendor-published AppExchange package, Datadog for Salesforce Service Cloud. It works in the other direction from the log integration: it creates Service Cloud incidents from Datadog monitors, so an alert becomes a case the support team can work.

TODO

Capabilities (dashboards, monitors and alerting, APM, correlation with pipeline telemetry from GitHub Actions); FedRAMP authorisation status and level.

Splunk

Splunk connects to the org through an OAuth 2.0 flow with a dedicated integration user. It never connects with a person's username, password, and security token.

The Splunk add-ons for Salesforce

Splunk's Salesforce integrations are Splunk add-ons, published on Splunkbase, Splunk's own app marketplace. They are installed in Splunk, not in Salesforce: nothing is installed through AppExchange, and no package goes into the org. The Salesforce side of the setup is an OAuth app and a dedicated integration user with access to the data being collected.

  • Splunk Add-on for Salesforce (documentation) collects Event Log Files and the results of SOQL queries against Salesforce objects through the REST API. It maps the data to Splunk's Common Information Model, so it works with Splunk Enterprise Security, the PCI Compliance app, and IT Service Intelligence. It runs on Splunk search heads and heavy forwarders, or on the Inputs Data Manager in Splunk Cloud Platform; universal forwarders are not supported.
  • Splunk Add-on for Salesforce Streaming API subscribes through the Streaming API to PushTopic events, generic events, platform events, and Change Data Capture events, for near-real-time ingestion. Platform events include Nebula Logger's LogEntryEvent__e. Every event it receives counts against the org's daily delivery allocation for external subscribers; see Platform Event Limits.
  • Authentication: the Salesforce add-on supports a username, password, and security token, or OAuth 2.0 with either the client credentials or the authorisation code flow.

Splunk and FedRAMP

The FedRAMP authorisations of Splunk, and two cautions

Splunk Cloud Platform is FedRAMP authorised at two impact levels, both hosted in AWS GovCloud, and is also offered for DoD Impact Level 5:

Offering Impact level Authorisation Authorised
Splunk Cloud Platform for FedRAMP Moderate Moderate Agency October 11, 2019
Splunk Cloud Platform for FedRAMP High High Agency September 13, 2024

Two cautions apply before relying on the Salesforce add-ons in a FedRAMP environment:

  • An add-on is not automatically inside the authorisation. Splunk states that apps listed on Splunkbase can be installed in its FedRAMP and DoD IL5 environments, but that their presence on Splunkbase "does not indicate that they are authorized for use in regulated compliance environments" (Splunk Cloud Platform Service Details). Splunk publishes the list of products and apps included within its FedRAMP authorisations on its Compliance at Splunk page, under US Public Sector. Confirm the Salesforce add-ons are on that list, or covered by the agency's own authorisation, before using them.
  • The authorisation covers Splunk Cloud Platform only. Splunk Enterprise run on the customer's own infrastructure is not a FedRAMP-authorised cloud service; it sits inside the customer's own authorisation boundary and is assessed there.

TODO

Capabilities (SIEM use with Splunk Enterprise Security, dashboards, alerting, correlation with pipeline telemetry); whether the Salesforce add-ons appear on Splunk's FedRAMP in-scope list (Compliance at Splunk, US Public Sector tab); Splunk Observability Cloud's FedRAMP status.

Sources: