Operational Logs

Studio writes structured Worker diagnostics for service failures and important lifecycle transitions. Use the local development terminal or your Cloudflare Worker logging tools to inspect them. Audit Log separately records major user and Operations activity in Studio D1.

Log Structure

The top-level message is an English description. Studio-owned fields are under $zeropress; Cloudflare may add its own platform metadata.

{
  "message": "Concise diagnosis",
  "$zeropress": {
    "code": "STABLE_OPERATIONAL_CODE",
    "resource": "DB",
    "action": "operation_name",
    "errorType": "Error",
    "guidance": "Recovery action when the cause is known."
  }
}

Filter by the stable code, then use the resource, action, and available operation ID to identify the affected workflow. An API can return a generic error while the server records a more specific diagnostic.

Expected Rejections

An invalid password, validation error, denied permission, or exhausted attempt budget is not necessarily an infrastructure failure. Expected request rejections are not logged as operational errors. A denied response with no console message does not by itself mean logging is broken.

Repeated system-status polling also need not produce another identical message. Studio suppresses repeated configuration incidents within a Worker isolate until the incident changes or clears.

Privacy and Retention

Operational logs omit passwords, tokens, session values, request bodies, exception text, and raw external responses. Verified maintenance actions can include the initiating administrator’s ID and email. Token-only recovery and rejected authentication omit that attribution.

Their retention follows the configured logging platform. The 365-day audit and 30-day audit-IP policies do not set Worker-log retention. Database restore also does not rewind logs already held by the logging platform.

Use the source repository’s operational log catalog for individual codes and their diagnostic fields.