Logs
Every service container ships its stdout/stderr to a per-project log store. The portal's Logs section gives you one unified timeline plus a tab per service, all searchable without leaving the browser.
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.
The reason the platform collects them centrally is that a single user action crosses several services — a sign-in touches GoTrue, the query that follows touches PostgREST and Postgres, and the function it calls runs somewhere else again. Reading each service separately means guessing where the failure started. The unified timeline puts them in one order so you can follow the request instead of the service.
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 | Unified timeline + a tab per service, filterable |
| CLI | shovelbase logs <service> — the same per-service tabs, in the terminal |
| SDK / HTTP | None — logs are something you read, not something an app calls |
Unified
A single stream across every service — filter by source, level, or message. This is the fastest way to see what happened around a given time without knowing in advance which service to blame.
Per-service tabs
| Tab | What lands here |
|---|---|
| Functions | console.log/error output and uncaught errors from every edge function and MCP endpoint invocation |
| REST | PostgREST request logs — /rest/v1 queries |
| Auth | GoTrue request logs — sign-ups, sign-ins, password resets, admin API calls |
| Storage | storage-api request logs — uploads, downloads, signed URL issuance |
| Queues | Queue management actions (create, delete, test sends) and trigger function invocations |
| Websites | Every request served for a published static site |
| Postgres | RDS logs for the project's own Postgres instance |
From the CLI
shovelbase logs functions --lines 100 # rest | auth | storage | functionsshovelbase logs queues # | queues | sites | postgresshovelbase logs auth --project my-appLogs are project-scoped — a source has its own Logs page covering its own functions and database, since it has no Auth/Storage/Websites to log. For request-rate and error-rate graphs (rather than raw log lines), see the portal's Observability pages, described in Using the portal.
Function console.log calls typically show up within a few seconds; see Functions for how to deploy a function that writes them.