# Logs

> Runtime output is a signal: tail it locally, stream it hosted.

[HTML version](https://snoozestack.com/docs/logs/) · [Docs index](https://snoozestack.com/llms.txt)

Logs are [Signals](https://snoozestack.com/docs/signals.md) 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](https://snoozestack.com/docs/runtime.md), 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

```bash title="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

```bash title="terminal"
snoozestack logs functions --lines 100    # the runtime's own log (auth | storage | functions all read it)
snoozestack logs queues                   # queue and website activity: queues | sites
snoozestack logs auth --project my-app
```

Logs are project-scoped, and bulk reads go through the same [export API](https://snoozestack.com/docs/signals.md) (`?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.