insightral for Neon — monitor through cold-starts and branch switches

Cold-start latency detection

When Neon suspends an idle compute endpoint and your application makes the next query, Postgres must resume before the connection completes. That resumption typically adds 100–500 ms to the first connection attempt — a cold start. Under normal circumstances this is acceptable. When it recurs frequently or when the delay spikes beyond a second, it signals that your compute is suspending more often than your traffic pattern warrants.

insightral tracks connection time distribution via the pg_stat_activity backend start time against query start time. When the gap between backend establishment and first query arrival is consistently higher than baseline for your endpoint, it fires a cold-start latency finding. The finding includes the sampled connection time, the p95 across the current observation window, and a recommendation to adjust the Neon auto-suspend threshold for your compute size.

• Fires when p95 connection establishment time exceeds 300 ms
• Includes time-of-day breakdown to distinguish traffic troughs from misconfiguration
• Links to Neon console compute settings for direct threshold adjustment

Branching overhead and ghost connections

Neon database branching lets you create instant copy-on-write clones of your database for preview environments, CI runs, and migrations. The mechanism is storage-efficient and fast. The operational challenge is that branches accumulate. A preview deployment torn down six weeks ago may still have a compute endpoint that restarts periodically — triggered by a health check, a lingering CI job, or a misconfigured connection pool that retained the branch DSN.

These stale compute endpoints show up in pg_stat_activity as short-lived connections from application hostnames that no longer map to active deployments. insightral flags connections whose application name or client address matches a pattern consistent with ephemeral infrastructure — CI runner IP ranges, preview deployment hostnames, or connection strings that arrive infrequently from rotating source addresses. The finding lists client addresses, reconnection frequency, and an estimate of compute-time cost.

On Neon's consumption-based billing, ghost connections from stale branches translate directly to compute-hours you are paying for with no corresponding application benefit.

Autoscaling threshold tuning

Neon autoscaling adjusts compute capacity between a configured minimum and maximum CU (compute unit) range based on load. The threshold at which scaling kicks in is not always obvious from the Neon console alone. You can be running at 90% of your current CU allocation — close enough that any query spike will breach the limit and queue — without any alert telling you that you are operating with no headroom.

insightral tracks three signals that indicate insufficient autoscaling headroom. The connection saturation rule watches pg_stat_activity active connection count against max_connections. The temporary file spill rule watches for sort and hash operations that cannot fit in work_mem — a common symptom of under-provisioned compute with a conservative memory configuration. The long-running transaction rule catches queries waiting longer than expected, which often accompanies compute contention during a CU scale-up event.

Each finding includes the current value, the threshold that triggered it, and a specific recommendation for your Neon autoscaling minimum or maximum — not “consider scaling up” but a concrete CU range derived from your observed connection count and memory pressure at peak load.