Monitor Neon with Sazabi

Last verified on Nov 8, 2026.

Neon runs Postgres on computes that start, stop and branch. That makes its logs different from a database on a fixed server. A branch for a pull request, a compute that scaled to zero overnight and a production endpoint can all log into the same project. Telling them apart is half the work.

Sazabi is AI-native observability and security. It receives Neon's Postgres logs over OpenTelemetry, and its agent can also work with Neon directly through an MCP connector.

What Sazabi reads from Neon

The log source is Neon's built-in OpenTelemetry integration, set up from the project's Integrations page. You export Postgres logs, choose the HTTP protocol, leave Metrics off and set the authentication to Bearer with any non-empty placeholder. There is no agent to run. Neon documents the Postgres logs as errors, warnings, connection events and other Postgres activity, and the export is in Beta on the Scale plan (Neon: OpenTelemetry).

Two details from Neon matter for reading the data. The integration sends data for every compute in the project, so a project with several branches, each with a compute, produces logs for each one. And service.name is the only resource attribute Neon exports. Set it to something stable, such as neon-checkout-db, because it is the label that separates one project from another in Sazabi. The Neon log source page has the full setup.

The Neon MCP connector is a separate method. It gives the agent tools to manage projects and databases, work with branches and run SQL queries and migrations.

Questions it answers

• Did the connection errors start when a branch compute woke up?
• Which Postgres errors appeared in the hour after the migration?
• Is the error from the production project or a test project, by service.name?
• Is a long-running query holding things up right now?
• Does a fix work on a branch before it reaches the main branch?

A worked example: errors after a migration

Say a migration ran on a branch and the app began to fail. Logs from the export show what Postgres said, and the connector shows what the database looks like now. Start with the logs:

sazabi logs ask "Show Neon Postgres error and warning records for service.name neon-checkout-db in the last 2 hours, newest first"

If the errors name a missing column or a failed constraint, the migration is the cause, and the agent can describe the table through the connector to confirm. If instead the errors are connection errors clustered at one moment, check whether the compute had been suspended. Neon says a suspended compute emits no logs, so a quiet gap followed by connection events is the usual sign of a compute waking after Scale to Zero.

Neon's MCP server also has an inspect_database tool that runs 15 read-only checks, such as table sizes, unused indexes and stalled-queries, which reports active queries running longer than 30 seconds. The tool runs inside a read-only transaction. Ask the agent to run stalled-queries when the logs show timeouts and no errors.

Keep the connector narrow

Sazabi's docs say the Neon connector grants full read and write access. Neon's own guidance is to avoid pointing MCP agents at production databases, to review actions before they run, and to limit access with read-only mode, a Postgres role with limited grants and category filtering. The Sazabi CLI offers --read-only and --project-id for the connector. Use both for investigations, and keep write access for branches you are willing to lose.

How it fits with other integrations

A Neon database usually serves an app on a hosting platform, so read it next to Vercel or Render logs. For another hosted Postgres with its own log export, see Supabase. The export speaks OTLP, which the OpenTelemetry integration explains, and the integrations page lists the rest of the catalog.