Logs

Logs are Signals with type = log: a function's console.log/console.error output and the runtime's own request records join your product events, metrics, traces, and audits in the same envelope and the same store — so “what exactly happened at 2:14pm” and “what was the user doing at 2:14pm” are one timeline, not two systems.

Why use it

Logs are for the question no dashboard answers: what exactly happened to this one request? Metrics tell you error rates went up; only the log line tells you which constraint was violated, and on whose row.

Because the whole backend is one runtime, a user action doesn't scatter across services you have to read separately — the sign-in verification, the function it reached, and that function's query all happened in one process, and their records land in one ordered stream.

Which is also the argument for logging deliberately in your functions: a console.log with the ids involved is often the only record of why a background job made the decision it did — nobody was watching when it ran.

Surface	Availability
Portal UI	The Signals stream, filtered to logs — same console page as everything else the app reports
CLI	`snoozestack logs <service>` hosted; `snoozestack signals tail --type log` locally
SDK / HTTP	None to write logs — `console.log` in a function is captured; `capabilities.signals.emit("log", …)` for structured ones

Locally#

terminal

snoozestack dev --verbose                       # request lines in the terminal
snoozestack signals tail --type log             # the local store, live
snoozestack signals query --type log --lines 200

Hosted#

terminal

snoozestack logs functions --lines 100    # auth | storage | functions
snoozestack logs queues                   #   | queues | sites | postgres
snoozestack logs auth --project my-app

Logs are project-scoped, and bulk reads go through the same export API (?type=log) as every other signal type — so an external log viewer is a consumer of one documented endpoint, not a special integration. For “who changed the project” rather than “what did it do,” see snoozestack audit — a change history across the console, CLI, and MCP.