Containers: Stream container stdout/stderr to Workers Observability logs

[alexminza]

Describe the solution

Summary

Container stdout/stderr from processes started via sandbox.startProcess() should be continuously forwarded to Workers Observability (dashboard logs, wrangler tail), similar to how console.log() in Workers is captured automatically.

Current behavior

• console.log() in the Worker → visible in Workers Observability ✅
• Container startProcess() stdout/stderr → not forwarded to Workers Observability ❌
• observability.logs.enabled: true in container config captures Sandbox runtime logs, but not stdout/stderr from user processes started via startProcess()
• The SDK's canonical structured events (process.exit, command.exec, etc.) do reach Workers Logs (auto-indexed when emitted as objects), but these are lifecycle events — not the raw stdout/stderr content of the process
• process.getLogs() returns a point-in-time snapshot — full buffer, no offset/cursor, no incremental reads

What already exists (partial)

Since this was filed, the SDK does expose real-time streaming of a process's output:

• sandbox.streamProcessLogs(processId) → ReadableStream of SSE LogEvents (type: stdout | stderr | exit | error), consumed via parseSSEStream<LogEvent>()
• execStream() / exec(command, { onOutput }) for command output

This satisfies the event-based-API request below. It does not close the gap, because:

1. It follows only the exact PID passed to startProcess(). If that process spawns children (backgrounded subprocesses, or a supervisor shell that runs the real workload as a child), their output is visible only as long as they inherit the handle process's stdout fd — and a child that re-execs or is re-parented (a full-process restart, setsid, daemonization) drops off the stream entirely. getLogs() has the same limitation.
2. There is still no path to Workers Observability / wrangler tail without writing a Worker that consumes the stream and re-emits each line via console.log().

Workarounds

1. GET /debug/logs endpoint — Worker route that calls process.getLogs() on demand and returns stdout/stderr as JSON. Point-in-time; requires manual polling.
2. streamProcessLogs() + console.log() re-emit — consume the SSE stream in the Worker and forward each LogEvent to console.log() so it lands in Workers Observability. Works, but is boilerplate every project re-implements, and only for handle-held processes.
3. SSH (wrangler containers ssh <instance-id>) — interactive access, not suitable for monitoring.

None of these provide zero-config, continuous log visibility comparable to docker logs -f or platform-managed containers.

Proposed solution

Either would close the remaining gap:

1. Automatic forwarding — startProcess() stdout/stderr automatically appears in Workers Observability when observability.logs.enabled: true, with no Worker code. (Most ergonomic.)
2. Incremental reads — process.getLogs({ since: timestamp }) or process.getLogs({ offset: byteOffset }) for efficient polling without re-reading the full buffer.

(The earlier "event-based streaming API" ask is now met by streamProcessLogs() — see above.)

Use case

Running an app inside a Cloudflare Container via the Sandbox SDK. The app produces structured logs on stdout that are essential for debugging failures and configuration problems. Today those logs are invisible in Observability unless you SSH in or write a custom stream-and-re-emit Worker.

Environment

• @cloudflare/sandbox 0.7.21 (streaming APIs verified present)

[mrmahan8595-creator]

Describe the solution

Summary

Container stdout/stderr from processes started via sandbox.startProcess() should be continuously forwarded to Workers Observability (dashboard logs, wrangler tail), similar to how console.log() in Workers is captured automatically.

Current behavior

• console.log() in the Worker → visible in Workers Observability ✅
• Container startProcess() stdout/stderr → not forwarded to Workers Observability ❌
• observability.logs.enabled: true in container config captures Sandbox runtime logs, but not stdout/stderr from user processes started via startProcess()
• The SDK's canonical structured events (process.exit, command.exec, etc.) do reach Workers Logs (auto-indexed when emitted as objects), but these are lifecycle events — not the raw stdout/stderr content of the process
• process.getLogs() returns a point-in-time snapshot — full buffer, no offset/cursor, no incremental reads

What already exists (partial)

Since this was filed, the SDK does expose real-time streaming of a process's output:

• sandbox.streamProcessLogs(processId) → ReadableStream of SSE LogEvents (type: stdout | stderr | exit | error), consumed via parseSSEStream<LogEvent>()
• execStream() / exec(command, { onOutput }) for command output

This satisfies the event-based-API request below. It does not close the gap, because:

1. It follows only the exact PID passed to startProcess(). If that process spawns children (backgrounded subprocesses, or a supervisor shell that runs the real workload as a child), their output is visible only as long as they inherit the handle process's stdout fd — and a child that re-execs or is re-parented (a full-process restart, setsid, daemonization) drops off the stream entirely. getLogs() has the same limitation.
2. There is still no path to Workers Observability / wrangler tail without writing a Worker that consumes the stream and re-emits each line via console.log().

Workarounds

1. GET /debug/logs endpoint — Worker route that calls process.getLogs() on demand and returns stdout/stderr as JSON. Point-in-time; requires manual polling.
2. streamProcessLogs() + console.log() re-emit — consume the SSE stream in the Worker and forward each LogEvent to console.log() so it lands in Workers Observability. Works, but is boilerplate every project re-implements, and only for handle-held processes.
3. SSH (wrangler containers ssh <instance-id>) — interactive access, not suitable for monitoring.

None of these provide zero-config, continuous log visibility comparable to docker logs -f or platform-managed containers.

Proposed solution

Either would close the remaining gap:

1. Automatic forwarding — startProcess() stdout/stderr automatically appears in Workers Observability when observability.logs.enabled: true, with no Worker code. (Most ergonomic.)
2. Incremental reads — process.getLogs({ since: timestamp }) or process.getLogs({ offset: byteOffset }) for efficient polling without re-reading the full buffer.

(The earlier "event-based streaming API" ask is now met by streamProcessLogs() — see above.)

Use case

Running an app inside a Cloudflare Container via the Sandbox SDK. The app produces structured logs on stdout that are essential for debugging failures and configuration problems. Today those logs are invisible in Observability unless you SSH in or write a custom stream-and-re-emit Worker.

Environment

• @cloudflare/sandbox 0.7.21 (streaming APIs verified present)

hacker