We keep expanding our backend observability. The most recent addition: you can now query backend logs outside the Console!
neon logs
reads what Neon Functions and Object Storage emit on a branch, with filters for source, severity, and message text. The same log stream is also available through the Neon MCP server, the Logs API, @neon/sdk, and raw Loki endpoints.
A quick recap: Functions and Object Storage #
neon logs
is in beta, and it currently covers Neon Functions and Object Storage on a branch. If you haven’t been following the progress of the Neon backend beta, these are the newer primitives sitting next to Lakebase Postgres (the Neon database):
Neon Functionsare serverless Node.js compute you deploy onto your Neon branch, so your backend code runs next to your database. They’re long-running enough for streaming agents and realtime work.Neon Object Storageis S3-compatible object storage built into a Neon branch, so you can deploy buckets that branch with your data. Point a standard S3 SDK or tool at your branch endpoint, authenticate with a Neon credential, and you’re done.
Logs coming soon for Postgres compute, Managed Better Auth, and AI Gateway
These don’t show up in neon logs
yet - working on it.
Inspect Functions and Object Storage logs from the CLI #
The Neon Console already had a Logs tab for Functions and Object Storage. What’s new is a branch-scoped CLI surface for the same log stream.
That matters when you’re debugging across the stack. A failed upload and a function error often show up in different places. With neon logs
, you query them the same way, from the same branch context the rest of the CLI already uses.
There’s three key subcommands:
neon logs query
: returns log records over a time window (defaults to the last hour, newest first)neon logs fields
: lists the fields a branch reports for filteringneon logs field-values <field>
: lists distinct values for a field (defaults to the last six hours)
Plus,
- You can filter by
--source function|storage
, service or scope name, severity, body text, or trace ID. Or pass--logql
for a raw LogQL expression when the structured filters aren’t enough. - Project and branch resolve from your CLI context, same as other branch-scoped commands. Pass
`--project-id`
and`--branch`
when you need to target something else. - Table output is the default. Use
`--output json`
or`--output yaml`
when you want the full records (and the pagination cursor) for scripts or an agent.
Review our docs for all the info.
Same logs in MCP, the API, and Loki #
The CLI isn’t the only surface: the same log stream is also available for your agents / programmatic tooling.
- The
Neon MCP serverexposes the same log workflow as read-only tools in theobservability
category. Once MCP is connected, you can ask your agent something like, “Why did my function error in the last hour? Check the logs.” - For scripts and apps, the same operations are in the
Logs API(OpenAPI) and@neon/sdk
- We’re also exposing raw Loki endpoints, for Grafana users - you can query Neon backend logs with tooling that already speaks LogQL
Try it #
If you haven’t spun up the Neon backend beta yet, this is a good moment! Create a project in AWS US East (Ohio), deploy a function and a bucket, then pull the logs from your terminal — or even better: ask your agent over MCP.