Logs

Every request a server-rendered storefront handles produces a log entry with its own ID. Together they are the first place to look when a page is slow, erroring, or returning something you didn't expect in production.

These are request logs from the running storefront. The logs a build produces are separate and covered in Deployments.

What a request log contains

Opening a single log gives you the request and response detail — parameters and headers on both sides. For server-rendered storefronts, console.log and console.error output from the request appears in the response logs too, which is what makes them useful for debugging SSR rather than just observing traffic.

Read logs

In Cockpit, open the site under Experience Studio → Sites and go to its Activity tab: recent server-rendered requests are listed there, filterable to failures only, and selecting a row opens the full entry. The site's Logging toggle, in its settings, is what turns this collection on and off.

Over the API:

# List recent request logs for a site
curl -s 'https://api.revenexx.com/v1/sites/<SITE_ID>/logs' \
  -H 'X-Revenexx-Tenant: <tenant-slug>' \
  -H 'X-Revenexx-Api-Key: <api-key>'

# Fetch one entry in full
curl -s 'https://api.revenexx.com/v1/sites/<SITE_ID>/logs/<LOG_ID>' \
  -H 'X-Revenexx-Tenant: <tenant-slug>' \
  -H 'X-Revenexx-Api-Key: <api-key>'

A log entry can also be deleted individually with DELETE /v1/sites/{siteId}/logs/{logId} — useful if something sensitive was logged by accident.

Static sites produce no request logs

Only server-rendered storefronts execute code per request, so only they generate request logs. A static site is served as files; there is nothing to log per request on the platform side. If you need traffic analytics for a static storefront, that is a job for an analytics tool rather than these logs.

Retention

Log retention is not currently documented, and you should not build on an assumed window. If you need a guaranteed retention period — for auditing, for a customer's compliance requirement, or just to keep more than the recent history — ship the logs somewhere you control rather than relying on the platform's request logs as the system of record.

Two practical patterns:

• Log structured events from your server routes to your own store, where you set the retention and the schema.
• Pull the logs periodically over the API and archive them.

Either way, keep personal data out of what you log in the first place. That is the reliable way to stay compliant, and it does not depend on a retention window.

Keep sensitive data out of logs

Because request and response detail is captured — including headers — treat logs as something that will be read. Don't log request bodies wholesale, don't log tokens or API keys, and be deliberate about console.log in server routes that handle buyer data. What you never write is the only thing you never have to expire.