Enable debug logging for data collection

The following methods control Web SDK diagnostic output. They do not enable tag-library logging for a standalone Web SDK implementation.

debugEnabled in the configure command: Set debugEnabled to true in your existing configure call. This setting is useful in development environments. If deployed in your site’s code, it enables logging for visitors who run that configuration.

alloy("configure", {
  datastreamId: "ebebf826-a01f-4458-8cec-ef61de241c93",
  orgId: "ADB3LETTERSANDNUMBERS@AdobeOrg",
  debugEnabled: true
});

Change the configuration value to false or omit it in subsequent deployments to restore the default. Do not run configure a second time on the same instance to toggle logging; use setDebug instead. A local debug override can take precedence over the configuration value. See debugEnabled for the configuration reference.

The setDebug command: Run the command against the appropriate Web SDK instance in your browser console:

alloy("setDebug", { enabled: true });

When finished, disable it:

alloy("setDebug", { enabled: false });

Running this command in your console changes your local instance, not other visitors’ browsers. If you put the same command in deployed site code, it affects visitors who execute that code. The local override can persist across page loads for that instance in the same-origin tab session when browser storage is available. See setDebug for more information.

The alloy_debug query string parameter: Add alloy_debug=true to the page URL, then load the page:

https://example.com/?alloy_debug=true

Use &alloy_debug=true if the URL already has query parameters. This parameter enables logging locally without changing deployed code. Web SDK reads the parameter when each instance is created, so it applies to every Web SDK instance on the page. When browser storage is available, the setting persists for the tab’s same-origin session, so removing the parameter alone does not disable logging. Load the page with alloy_debug=false or run setDebug with enabled: false to disable it. If the URL still contains alloy_debug=true, reloading it enables logging again.

Adobe Experience Platform Debugger: Open Adobe Experience Platform Debugger, select the Web SDK section, and enable debugging in its configuration tab. Turn the option off when you finish.

This procedure enables diagnostic output; using the Debugger for request or Edge inspection is covered in Inspect data collection requests.

On a page with a tag library, run the following in your browser console:

_satellite.setDebug(true);

This command exposes tag-library messages, including _satellite.logger output. For Web SDK instances managed by the Web SDK tag extension, the extension uses tag debug mode when configuring the SDK and forwards subsequent debug-mode changes to it. Do not assume that turning on debugging for a standalone or externally configured Web SDK instance also enables tag logging.

The Web SDK tag extension does not provide a debug toggle in its tags configuration UI. Use the console method for an extension-managed instance. Keep it out of tag rules.

To disable tag debug mode and the corresponding extension-managed SDK logging:

_satellite.setDebug(false);

Tag debug mode is stored in the browser’s local storage for the page’s origin. It persists across page loads and browser restarts until you disable it or clear the site’s data, and it does not enable logging for other visitors. See _satellite.setDebug() for scope and persistence details.

The tag library notifies the extension only when tag debug mode changes. If tag debug mode is already on but Web SDK messages are missing, a Web SDK override from setDebug or alloy_debug might have turned SDK logging off. Run _satellite.setDebug(false) and then _satellite.setDebug(true), or use the same Web SDK method that set the override.

The Server SDK writes diagnostic output to the server console, not the visitor’s browser.

Set debugEnabled: true in your existing server-side configure call to enable logging for the instance and the forRequest handles created from that configuration. The default is false. See debugEnabled for a complete configuration example.

For a targeted investigation, call setDebug on the request-scoped handle returned by forRequest. Logging changes only for that handle, so you can debug a single request without enabling it for all visitors:

const visitor = alloy.forRequest({ request: req });

await visitor.setDebug({ enabled: true });
await visitor.sendEvent({
  xdm: { eventType: "web.webpagedetails.pageViews" }
});

Calling setDebug on the top-level instance changes logging only for calls made directly on that instance, not for its request handles, until you disable it or the process restarts. To change the baseline for all request handles, update debugEnabled in the server’s configuration.

Messages identify the instance in square brackets, such as [alloy], and include configuration, method inputs/results, warnings, and errors. Review the server process’s output or the log destination to which your hosting environment routes it.

Use Mobile Core’s setLogLevel API to select diagnostic verbosity. Android defaults to LoggingMode.ERROR; iOS defaults to LogLevel.error. Set the desired level during app initialization before reproducing the issue.

Android: Enable verbose logging in your development app:

import com.adobe.marketing.mobile.LoggingMode
import com.adobe.marketing.mobile.MobileCore

MobileCore.setLogLevel(LoggingMode.VERBOSE)

View output in Android Studio’s Logcat for the running app process. Mobile SDK messages use the AdobeExperienceSDK tag, so filter with tag:AdobeExperienceSDK and make sure the log viewer allows debug and verbose messages. Restore error-level logging when finished:

MobileCore.setLogLevel(LoggingMode.ERROR)

iOS: Enable trace logging in your development app:

import AEPCore
import AEPServices

MobileCore.setLogLevel(.trace)

View the running app’s console in Xcode and filter for AEP SDK. Restore error-level logging when finished:

MobileCore.setLogLevel(.error)

Returning to error level reduces diagnostic output; it does not suppress errors. These calls change logging in the running app, not other installations. Ensure your initialization code does not re-enable verbose logging on the next launch or in a production build.

See the Mobile Core API reference for Java, Objective-C, supported levels, and version-specific details. For React Native or Flutter, use the API exposed by your Mobile SDK wrapper rather than copying native calls directly into wrapper code. For connected event inspection rather than runtime console output, see Assurance.