Storefront Next includes a built-in structured logger that outputs JSON to stdout. The logger automatically enriches each log entry with a correlation ID and request context, making requests easy to trace across your application and search in Log Center.
Use getLogger(context) to get a request-scoped logger. It automatically includes the correlation ID, HTTP method, and path in every log entry.
1import { getLogger } from "@/lib/logger.server";
2
3export async function loader({ context }: LoaderFunctionArgs) {
4 const logger = getLogger(context);
5 logger.info("Product loaded", { productId: "sku-123" });
6 logger.warn("Inventory low", { remaining: 2 });
7 logger.error("Payment failed", { error: new Error("timeout") });
8}Use createLogger() when router context isn’t available, such as in client-side code or utility functions.
1import { createLogger } from "@/lib/logger";
2
3const logger = createLogger();
4logger.info("Variant selected", { sku: "var-456" });Pass an optional metadata object as the second argument to any log method. Metadata fields are included as JSON properties in the log output.
1logger.info("Order placed", {
2 orderId: "order-789",
3 total: 149.99,
4 itemCount: 3,
5});The logger automatically serializes error instances with name, message, and stack fields.
Storefront Next supports four log levels, from most to least severe:
| Level | Use for |
|---|---|
error | Unrecoverable failures within a request |
warn | Recoverable problems: fallback paths, retries, degraded behavior |
info | Observable outcomes: request completed, action succeeded/failed, state changes |
debug | Internal progress: intermediate steps, useful for local debugging |
On Managed Runtime, configure the log level in your environment settings:
Alternatively, set the log level via the Managed Runtime API. Call projects_target_partial_update with "log_level" in the payload.
For local development, use the SFCC_LOG_LEVEL environment variable:
1SFCC_LOG_LEVEL=debug pnpm dev| Value | Logs emitted |
|---|---|
error | error only |
warn | error + warn |
info | error + warn + info |
debug | all messages |
| (not set) | warn in production, info otherwise |
In production, logs are output as structured JSON (ndjson). Each entry contains:
| Field | Description |
|---|---|
level | Log severity: error, warn, info, or debug |
msg | The log message |
correlationId | A unique ID for tracing a request across log entries |
method | HTTP method (GET, POST, etc.) |
path | URL pathname of the request |
Example:
1{
2 "level": "info",
3 "correlationId": "a1b2c3d4",
4 "method": "GET",
5 "path": "/products/shoes",
6 "msg": "Product loaded",
7 "productId": "sku-123"
8}In development, logs are pretty-printed with colors and timestamps for readability.
Every incoming request is assigned a correlation ID — either extracted from the x-correlation-id request header or generated automatically. All log entries for that request share the same correlationId, which lets you trace a single request end to end.
Log Center lets you search and filter production logs from Managed Runtime and your B2C Commerce instance.
To access MRT logs in Log Center:
MRT logs in Log Center are available for any environment with Log Center logs enabled and a B2C Commerce instance associated. Marking the environment as production isn’t required. There can be a delay of up to 15 minutes between an event and the log appearing in Log Center.
Note
$PROJECT.$ENVIRONMENT).Use the correlationId field to filter all log entries for a single request.
j