This page provides a comprehensive reference for all metrics and log fields that Neon exports to observability platforms through integrations like Datadog and OpenTelemetry.
Available metrics
Neon makes the following metrics available for export to third parties through our observability integrations.
All metrics include the following labels:
project_idendpoint_idcompute_idjob
Here's an example of the metric db_total_size with all labels:
neon_db_total_size{project_id="square-daffodil-12345678", endpoint_id="ep-aged-art-260862", compute_id="compute-shrill-blaze-b4hry7fg", job="sql-metrics"} 10485760note
In Datadog, metric labels are referred to as tags. See Getting Started with Tags in the Datadog Docs.
| Name | Job | Description |
|---|---|---|
| neon_connection_counts | sql-metrics | Total number of database connections. The state label indicates whether the connection is active (executing queries), idle (awaiting queries), or in a variety of other states derived from the pg_stat_activity Postgres view. |
| neon_db_total_size | sql-metrics | Total size of all databases in your project, measured in bytes. |
| neon_lfc_approximate_working_set_size_windows | sql-metrics | Approximate working set size in pages of 8192 bytes. The metric is tracked over time windows (5m, 15m, 1h) to gauge access patterns. Duration values: duration="5m", duration="15m", duration="1h". |
| neon_lfc_cache_size_limit | sql-metrics | The limit on the size of the Local File Cache (LFC), measured in bytes. |
| neon_lfc_hits | sql-metrics | The number of times requested data was found in the LFC (cache hit). Higher cache hit rates indicate efficient memory use. |
| neon_lfc_misses | sql-metrics | The number of times requested data was not found in the LFC (cache miss), forcing a read from slower storage. High miss rates may indicate insufficient compute size. |
| neon_lfc_used | sql-metrics | The amount of space currently used in the LFC, measured in 1MB chunks. It reflects how much of the cache limit is being utilized. |
| neon_lfc_writes | sql-metrics | The number of write operations to the LFC. |
| neon_max_cluster_size | sql-metrics | The neon.max_cluster_size setting in MB. |
| neon_pg_stats_userdb | sql-metrics | Aggregated metrics from the pg_stat_database Postgres view. We collect stats from the oldest non-system databases based on their creation time, but not for all databases. Only the first X databases (sorted by creation time) are included. datname: The name of the database kind: The type of value being reported. One of the following: - db_size: The size of the database on disk, in bytes ( pg_database_size(datname))- deadlocks: The number of deadlocks detected - inserted: The number of rows inserted ( tup_inserted)- updated: The number of rows updated ( tup_updated)- deleted: The number of rows deleted ( tup_deleted) |
| neon_replication_delay_bytes | sql-metrics | The number of bytes between the last received LSN (Log Sequence Number) and the last replayed one. Large values indiciate replication lag. |
| neon_replication_delay_seconds | sql-metrics | Time since the last LSN was replayed. |
| host_cpu_seconds_total | compute-host-metrics | The number of CPU seconds accumulated in different operating modes (user, system, idle, etc.). |
| host_load1 | compute-host-metrics | System load averaged over the last 1 minute. Example: for 0.25 vCPU, host_load1 of 0.25 means full utilization, >0.25 indicates waiting processes. |
| host_load5 | compute-host-metrics | System load averaged over the last 5 minutes. |
| host_load15 | compute-host-metrics | System load averaged over the last 15 minutes. |
| host_memory_active_bytes | compute-host-metrics | The number of bytes of active main memory. |
| host_memory_available_bytes | compute-host-metrics | The number of bytes of main memory available. |
| host_memory_buffers_bytes | compute-host-metrics | The number of bytes of main memory used by buffers. |
| host_memory_cached_bytes | compute-host-metrics | The number of bytes of main memory used by cached blocks. |
| host_memory_free_bytes | compute-host-metrics | The number of bytes of main memory not used. |
| host_memory_shared_bytes | compute-host-metrics | The number of bytes of main memory shared between processes. |
| host_memory_swap_free_bytes | compute-host-metrics | The number of free bytes of swap space. |
| host_memory_swap_total_bytes | compute-host-metrics | The total number of bytes of swap space. |
| host_memory_swap_used_bytes | compute-host-metrics | The number of used bytes of swap space. |
| host_memory_swapped_in_bytes_total | compute-host-metrics | The number of bytes that have been swapped into main memory. |
| host_memory_swapped_out_bytes_total | compute-host-metrics | The number of bytes that have been swapped out from main memory. |
| host_memory_total_bytes | compute-host-metrics | The total number of bytes of main memory. |
| host_memory_used_bytes | compute-host-metrics | The number of bytes of main memory used by programs or caches. |
Postgres logs
Neon can export Postgres logs to observability platforms, providing visibility into database activity, errors, and performance. These logs include:
- Error messages and warnings
- Connection events
- System notifications
Log fields and metadata
Logs include the following labels and metadata for filtering and organization:
project_idendpoint_id- Timestamp
- Log level
- And other standard PostgreSQL log fields
note
During the beta phase, you may see some Neon-specific system logs included. These will be filtered out before general availability (GA).
Performance considerations
Enabling log export may result in:
- An increase in compute resource usage for log processing
- Additional network egress for log transmission (Neon does not charge for data transfer on paid plans)
- Associated costs based on log volume in your observability platform
note
Neon computes only send logs and metrics when they are active. If the Scale to Zero feature is enabled and a compute is suspended due to inactivity, no logs or metrics will be sent during the suspension. This may result in gaps in your data.
Additionally, if you are setting up an integration for a project with an inactive compute, you'll need to activate the compute before it can send data. To activate it, simply run a query from the Neon SQL Editor or any connected client.
Technical details
Neon processes logs directly on each compute instance using rsyslogd, an industry-standard open source logging utility. This compute-level processing means that log collection contributes to your compute's resource usage.
Integration guides
For platform-specific setup instructions and examples, see:
- Datadog integration - Setup instructions, dashboard configuration, and Datadog-specific features
- OpenTelemetry integration - OTLP configuration for any compatible observability platform
Need help?
Join our Discord Server to ask questions or see what others are doing with Neon. Users on paid plans can open a support ticket from the console. For more details, see Getting Support.