Monitoring the health of your headless application is critical to ensuring exceptional customer experiences and stable operations, both during the holidays and throughout the year. When an API call slows down or a login fails during peak traffic, you don’t have time to guess which layer of the stack is responsible. You need immediate visibility to diagnose the issue and get back to business. Yet navigating the metrics scattered across Log Center, dashboards, and debugging tools can be overwhelming without a clear strategy.
In this post, we’ll show you how to cut through the noise and leverage the observability tools of Salesforce B2C Commerce using the latest enhancements, such as streaming logs and server-side timings. These tools allow you to pinpoint bottlenecks and debug complex integrations faster, ensuring that your application is ready for the holiday season.
Log Center
Log Center is an application that you can use to view realm log messages generated from system and custom code. Several key tools in Log Center can help you monitor application health.
Monitor performance using the Log Center Metrics Dashboard
The Log Center Metrics Dashboard is a centralized analysis tool for B2C Commerce administrators that provides near real-time monitoring of system performance. Coverage includes application performance, sales, embedded content delivery network (eCDN), Salesforce Commerce API (SCAPI), and Managed Runtime (MRT).
In the dashboard, you can filter by realms, SCAPI families, and third-party services. You get near real-time monitoring of SCAPI operations and hooks with a delay of up to five minutes. You can also save searches and configure automated notifications for proactive monitoring. The dashboard screenshot below shows request latency results over a 30 day period for the shopper-products SCAPI API.
View authentication logs in Log Center
Since the B2C Commerce 24.9 release, the Shopper Login and API Access Service (SLAS) has emitted logs to Log Center. This is crucial to observing shopper login trends, potential misconfigurations, and indications of application problems.
For example, frequent HTTP 401 errors often signal problems with your login page. Similarly, errors with refresh tokens may indicate misconfiguration or timing issues with your SLAS token handling.
SLAS logs are available by clicking the slas service type in your Log Center filters.
Access eCDN logs from Log Center
Just in time for the holidays, the Log Center release 25.10 now includes eCDN error logs for proxy zones on production instances. Previous eCDN logs could be retrieved manually through Business Manager (for up to seven days) or delivered via eCDN Logpush to your own Amazon S3 bucket.
Adding eCDN logs to Log Center helps you correlate edge errors with application issues. This simplifies debugging across Managed Runtime, SLAS, or the Script API. eCDN error logs in Log Center are JSON formatted using the Cloudflare logs format.
Here’s an example HTTP 502 error (with irrelevant fields removed):
In this example, the request for a product has triggered a 500 (Internal Server Error) error response. We can also see the hostname and the eCDN zone name. An error of this type may indicate errors in a custom hook implementation, and it would be prudent to correlate this with nearby Script API errors to narrow down the source of the issue.
Save searches in Log Center
Log Center’s saved searches tool allows administrators and developers to save custom search queries for recurring use and monitoring. After configuring search parameters, you can save your search via Search > New Search > Save search, and retrieve it later via Search > Manage Saved Searches. In addition, URLs can be shared with team members for collaborative monitoring.
The tool’s primary capability is automated, recurring notifications based on search criteria. You can configure notifications to run at specified intervals with options to always send notifications, or set thresholds to only receive notifications when result counts exceed a specific number.
As a best practice, set meaningful thresholds and time intervals to avoid notification fatigue and focus on significant issues rather than every occurrence. In the screenshot example below, we have set notifications for excessive HTTP 401 errors, which may indicate an issue with our login page or automated bot attack.
Stream logs with Log Center
Log streaming sends logs directly to third-party aggregation tools and supports major platforms like Datadog, Dynatrace, Splunk, New Relic, and generic HTTP endpoints.
You can aggregate logs into existing application monitoring infrastructure for real-time analysis, alerting, and troubleshooting, combining B2C commerce logs with information from other parts of your infrastructure. Configuration is done through an intuitive UI in Log Center where you set up streaming connections, API keys, endpoints, and filtering criteria.
This eliminates the need for custom log scraping scripts and enables you to leverage existing log analysis tools and workflows for continuous, automated log delivery.
PWA Kit
If your storefront is built using PWA Kit, there are a number of tools you can use to debug operational and performance issues.
Real-time Managed Runtime logs
Logs emitted by PWA Kit in Managed Runtime will be sent to Log Center for environments marked as production. You can use the mrt service type in the Log Center side bar to filter logs and display those sent from PWA Kit.
However, for non-production environments, developers will want to inspect the logs in real time as requests are made. For this, we can use the pwa-kit-dev utility, which is part of all PWA Kit projects but can also be used standalone.
Server timings
Server timings in PWA Kit provide detailed performance metrics for the server-side rendering (SSR) process of your PWA Kit-based storefront through the HTTP Server-Timing header. Each metric captures the duration of specific operations, including route matching, component loading, data fetching strategies, and rendering operations.
During local development, enable this by appending ?__server_timing to any URL (e.g., http://localhost:3000?__server_timing). To continuously track server timing metrics, set the SERVER_TIMING environment variable to true, though this increases log usage and isn’t recommended for production use. Timing data appears in the Server-Timing HTTP response header viewable in your browser’s DevTools Network tab (see example screenshot below).
These metrics should be used to debug performance issues with server side rendering and determine where bottlenecks may be. For example, slow or substantial “waterfall” requests will be visible in the ssr.fetch-strategies server timings. These are further broken down into query categories. High duration in render-to-string often points to overly complex React component trees. Move expensive calculations to hooks or browser rendering to clear the critical path.
Investigating issues with correlation IDs
Correlation IDs are tracking identifiers that trace specific API requests through the Salesforce Commerce API system. Two types exist: user-provided correlation IDs (via correlation-id header) and system-generated IDs (sfdc_correlation_id) in responses.
To investigate issues, navigate to Log Center and search for the ID using the search field or Log Center Query Language (LCQL) expressions like externalID:(your-correlation-id). Chain investigations by extracting correlation IDs from error results and searching for related entries to uncover broader error patterns.
As a best practice, ensure that correlation IDs contain only word characters, hyphens, and commas; other characters may break searchability. Most Commerce API endpoints automatically attach correlation IDs to log messages. For deeper troubleshooting, combine with the sfdc_verbose: true header for detailed JSON logs (subject to rate limiting).
Use case: Debugging performance in custom hooks
During development and testing, catching performance issues or exceptions early is a critical step before promoting code to production. A prime candidate for optimization is the getProducts endpoint, which is one of the most frequently called and customized endpoints in SCAPI shopper APIs.
Let’s walk through a scenario where we create a customization, trigger it, and then use observability headers to verify behavior and diagnose potential issues.
1. Implementing the hook
First, we’ll create a hook customization for dw.ocapi.shop.product.modifyGETResponse. Note that this hook fires for both getProducts and single getProduct calls.
We have implemented three specific best practices in the code below: feature switching, cache awareness, and error logging.
Why did we write it this way?
- Feature switching: It is common practice to disable functionality that doesn’t scale well during high-traffic events (like flash sales). By checking
enableOperation, we ensure that we can degrade gracefully without a code deployment. - Cache cardinality: Passing custom parameters (
c_customParam) alters the cache key, which can lower your cache hit percentage. Ideally, only pass these parameters when the client specifically needs the extra response data, and ensure that the client knows not to send them if the feature is disabled. - Correlated logging: If an unhandled exception occurs, or if you explicitly log an error, you need a way to find that specific event in Log Center. This is where the Correlation ID comes in.
2. Triggering the request
Now, let’s call our getProducts endpoint using the commerce-sdk-isomorphic.
To make debugging easier, we are passing specific headers. Note the usage of sfdc_verbose and a custom correlation-id.
3. Analyzing the response headers
This is where the B2C Commerce observability tools shine. By reviewing the response headers from the call above, we can verify that our hook is working and check the health of the system.
Here are the key headers to watch:
Example: HIT [1/1]
This indicates whether or not your request was served from the cache. If you see MISS
after repeated calls, you have a configuration issue. Check that you are relying on the
default cache expiration for the endpoint, or that you are explicitly setting
response.setExpires(number) within your hook.
Example: HOOK
This header confirms that a custom hook was executed during the request. If you don’t see
this header, verify that your hook is registered correctly in your hooks.json file.
sfdc_correlation_id
Example: 9a0ca468dd3d6006
Important: This is the system-generated ID, not the one you passed in the request.
However, when searching Log Center for exceptions, you can search using either
the value you passed in (my-trace-id-12345) or this system-generated value.
sfdc_load
Example: 25
This represents the overall system load as a percentage. During high-scale traffic events,
this number may rise above 50-60. If you see values exceeding 75, the system
is under heavy load; at this stage, you may begin to see instability or increased latency.
4. Reviewing the verbose log entry
Using the correlation ID from before, you can search Log Center for the verbose log entry. You can review detailed request information, which should look similar to the below example. For our use case, since we are concerned with performance, we can evaluate the runtime latency for both the entire request and for specific hooks, such as our getProducts hook.
Conclusion
True observability turns scattered data into actionable intelligence. Instead of reacting blindly to production incidents, the strategies outlined here empower you to see exactly how your headless implementation performs under pressure.
By mastering these tools, you move beyond simple error trapping and gain the ability to proactively optimize your application. Whether it is tuning a slow hook before it impacts conversion or catching a misconfiguration in your CDN, you now have the clarity required to solve problems quickly. Implement these practices today to build a more resilient storefront and give your team the confidence to handle peak traffic with ease.
Resources
- Documentation: Log Center Metrics Dashboard
- Documentation: View SLAS Error Logs in Log Center
- Documentation: Access eCDN Logs in Log Center
- Documentation: eCDN Logpush
- Documentation: Cloudflare HTTP Requests log format
- Documentation: Keyword Search in Log Center
- Documentation: Configure and Run a Log Center Searche
- Documentation: Set Up Log Center Streaming
- Documentation: Debug PWA Kit Apps: Server timing
- Documentation: View SCAPI Logs and Track Requests
About the author
Charles Lavery is a Principal Member of Technical Staff at Salesforce specializing in developer tooling, experience, DevOps and CI/CD.
Johnny Green is a Commerce Cloud Professional Services Senior Technical Architect specializing in the design and delivery of commerce solutions with a focus on headless, PWA Kit, and Composable Commerce.