Connections: Metric Reference

This page is the source of truth for the in-app Explain this panels on the Activity Explorer Connections tab. Each section is written once as a content partial under _explain/ and rendered both here and inside the dashboard's info panel (scripts/build-explain.mjs compiles the registry).

The Connections tab is available for PostgreSQL, Microsoft SQL Server, and Oracle databases.

Total Connections

The number of client connections observed on this database in the selected time window, across every state — executing, idle, and waiting alike.

How it's calculated

• The Logstag agent samples live session state on the activity interval (10 s by default).
• Each sampled session counts once, using its most recent sample in the window.
• The count respects the filters applied on the tab, and the trend arrow compares against the preceding window of the same length.

Source by engine

Engine	Source
PostgreSQL	pg_stat_activity — query-bearing client backends; internal background workers are not part of this surface
SQL Server	sys.dm_exec_sessions joined with sys.dm_exec_requests and sys.dm_exec_connections — system sessions and the agent's own connections are excluded
Oracle	v$session

Reading it

Watch the level against your connection-pool size. A slow climb that never comes back down usually means a pool leak or an application that opens connections without closing them; a sudden spike often accompanies a deploy or a retry storm. Split the total with the Active and Idle tiles before reacting — a high total made of idle connections is a different problem than a high total that is all active.

Active Connections

The number of connections that were executing work when sampled — running a statement rather than sitting idle or parked in an open transaction.

How it's calculated

• Each engine reports a native session state; Logstag maps it onto a shared state model, and this tile counts the sessions that map to Active.
• PostgreSQL: sessions with state active.
• SQL Server: sessions whose request is running or runnable, plus suspended sessions waiting on non-lock resources (they hold an executing request even while briefly suspended).
• Oracle: sessions with status ACTIVE that are not currently in a wait.
• The count uses each session's most recent sample in the window, with the tab's filters applied.

Reading it

This is your concurrency at a glance. Compare it against the database's CPU capacity: an active count persistently higher than the cores available means sessions are queuing for CPU. A sudden drop to zero while Total Connections stays high can be just as interesting — everything connected, nothing working — and usually points at a lock convoy or an upstream stall.

Idle Connections

The number of connections that were connected but doing nothing when sampled — no running statement and no open transaction.

How it's calculated

• Sessions whose engine-native state maps to Idle in Logstag's shared state model: idle on PostgreSQL, sleeping (with no open transaction) or dormant on SQL Server, INACTIVE on Oracle.
• Connections that are idle inside an open transaction are not counted here — they are tracked as their own state in the Connection States chart, because they hold locks and snapshot resources that plain idle connections do not.
• The count uses each session's most recent sample in the window, with the tab's filters applied.

Reading it

A healthy pool keeps a cushion of idle connections — that is what a pool is for. The number matters in proportion: if idle connections dominate the total and keep growing, the pool is oversized or connections are leaking. Zero idle connections under load means the pool is exhausted and new work is about to queue.

Avg Wait Time

The average time that waiting sessions had spent in their current wait, across the selected window. It answers "when sessions wait here, how long do they wait?"

How it's calculated

• The agent's activity samples record how long each waiting session has been in its wait.
• Logstag averages those durations across the sessions observed waiting in the window, with the tab's filters applied.
• The tile turns amber or red when the average crosses the warning or critical threshold, and the trend arrow treats rising as worse.

Reading it

Interpret it together with the number of waiters. A high average over one or two sessions is usually a single stuck query or an abandoned transaction; a moderate average over many sessions points at systemic contention — a hot table, an undersized pool, or storage latency. The Wait Events tab breaks the same waits down by category and event so you can see what is being waited on.

Connection States

A stacked history of connection counts by state across the selected window. Each bar is a sample bucket; each color is one state, and the legend toggles states on and off.

The states

• Active — executing a statement right now.
• Idle — connected, no running statement, no open transaction.
• Idle in Transaction — no running statement, but a transaction was left open. These sessions still hold locks and pin resources, which is why they get their own color.
• Waiting for Lock — blocked on a lock held by another session.
• Other — states that don't fit the categories above, including engine-internal ones.

Each engine reports its own native session states; Logstag maps them onto this shared model so the chart reads the same for PostgreSQL, SQL Server, and Oracle.

Reading it

The shape matters more than any single bar. A growing orange band (Idle in Transaction) is an application forgetting to commit — the classic prelude to lock pileups and bloat. A red band (Waiting for Lock) appearing suddenly correlates with the Blocking Chains tab; check there for the root blocker. A total height that ratchets upward without receding is pool growth worth investigating before it hits the connection limit.

Database Workloads

One row per connection observed in the selected window, using each session's most recent sample. Click a row (or its eye icon) to open the full session detail in place — session identity, state, timing, and the complete query text.

Columns

• PID — the engine's session identifier: the backend process id on PostgreSQL, the session id on SQL Server, the SID on Oracle.
• User — the database user the connection authenticated as.
• Database — the database the connection is attached to (hidden by default; enable it from the column picker).
• State — the shared state badge: Active, Idle, Idle in transaction, Waiting for lock, Disabled, or Other. Each engine's native states are mapped onto this model.
• Wait Event — the engine-native name of the wait the session is currently in, when it is waiting.
• Duration — how long the session's current query has been running, measured with the database server's own clock. Idle connections show zero.
• Query — the current statement, clamped to two lines in the table; open the row detail for the full text.

Columns can be filtered individually, sorted where the header allows it, and shown or hidden from the column picker — visibility choices persist in your browser.

How it's calculated

• The Logstag agent samples live session state on the activity interval (10 s by default).
• Each connection appears once with its latest sampled state; the tab's filters and pagination apply server-side.

Source by engine

Engine	Source
PostgreSQL	pg_stat_activity — query-bearing client backends
SQL Server	sys.dm_exec_sessions + sys.dm_exec_requests + sys.dm_exec_connections, with query text from sys.dm_exec_sql_text()
Oracle	v$session, with process and per-session statistics joined from v$process and v$sesstat

Reading it

Sort by Duration to surface the longest-running statements first. A row in Waiting for lock shows the blocker's PID in its detail view — cross-reference it with the Blocking Chains tab to see the whole chain. Recurring rows with the same query and rising duration are your candidates for the Query Explorer.