Overview Tab: Metric Reference
This page is the source of truth for the in-app Explain this panels on the
Activity Explorer detail view's Overview 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 Overview tab is available for PostgreSQL, Microsoft SQL Server, and Oracle databases.
Active Sessions
The number of sessions observed actively executing work on this database across the selected window's samples.
How it's calculated
- The Logstag agent samples live session state on the activity interval (10 s by default).
- Sessions whose engine-native state maps to active are counted across the window; the trend arrow compares against the preceding window of the same length.
Source by engine
| Engine | Source |
|---|---|
| PostgreSQL | pg_stat_activity |
| SQL Server | sys.dm_exec_sessions joined with sys.dm_exec_requests |
| Oracle | v$session |
Reading it
This is the database's concurrency at a glance — the same signal the Connections tab breaks down per session. Compare it against the CPU cores available to the database: a level persistently above the core count means sessions are queuing. A sudden spike usually accompanies a deploy, a retry storm, or a lock convoy forming; the Connections and Blocking Chains tabs show which.
Transaction Rate
The rate of transactions the database is committing, per second, averaged over the selected window.
How it's calculated
- The agent collects the engine's cumulative transaction counters; Logstag turns the window's growth into a per-second rate.
- The trend arrow compares against the preceding window of the same length.
- This tile appears for PostgreSQL and SQL Server. Oracle does not currently show a rate tile on this tab.
Source by engine
| Engine | Source |
|---|---|
| PostgreSQL | pg_stat_database transaction counters (xact_commit, xact_rollback) |
| SQL Server | the engine's transaction performance counters |
Reading it
This is your throughput baseline. Read it together with Active Sessions and Avg Query Time: rate up with flat latency is healthy growth; rate down while active sessions climb means work is arriving but not completing — usually blocking or resource saturation. A rate near zero on a database that should be busy is worth checking before anything else, starting with whether the application can reach it.
Deadlocks
The number of deadlocks the engine detected in the selected window. Unlike the Wait Events tab's Potential Deadlocks, this counts real occurrences — situations the engine resolved by killing a victim.
How it's calculated
- The agent collects each engine's deadlock counters; Logstag reports the growth within the window, with rising shown red.
Source by engine
| Engine | Source |
|---|---|
| PostgreSQL | the deadlocks counter in pg_stat_database |
| SQL Server | the engine's deadlock rate counters |
| Oracle | the change in the cumulative lock deadlock retry event counter |
Reading it
Zero is the only comfortable value. Every unit here is a transaction the engine chose to kill, which the application experienced as an error. One-off deadlocks under rare workloads happen; recurring ones are a code pattern — two paths taking the same locks in different orders — and the Blocking Chains tab plus the engine's own deadlock report will name the tables involved.
Avg Query Time
The average duration of the queries observed on this database in the selected window.
How it's calculated
- Derived from the durations of statements the agent observed in its activity samples across the window, with the trend compared against the preceding window of the same length.
- The unit adapts to the value — sub-second averages keep millisecond precision; larger averages switch to seconds or minutes.
- Rising is treated as a regression and shown red.
Reading it
Averages hide tails: a stable average with unhappy users usually means a slow minority of queries is buried under fast ones — the Query Explorer's per-query statistics find them. A rising average across the board, though, points at something systemic: a missing index after a schema change, growing data volume, or pressure visible in Resource Utilization below.
Resource Utilization
The database server's current resource pressure: CPU, memory, and network, each with a level bar and a health color.
How it's calculated
- The agent collects system metrics from the host it monitors alongside the database metrics.
- Each bar shows the latest sample for the server behind this database: CPU and memory as percentages, network as throughput.
- The bar's color reflects the health status for that resource.
Reading it
This card answers "is the machine the problem?" — the fastest triage split there is. High CPU with high Active Sessions is genuine workload; high CPU with few sessions is one expensive query. Memory near the top on a database server is not automatically bad — databases deliberately use memory as cache — but a sudden drop often means a restart. When everything here is green and queries are still slow, the cause is inside the database: look at wait events, not the hardware.
Recent Activities
A rolling record of notable activity on this database — recent operations with who ran them, on what, and how they ended.
Columns
- Timestamp — when the activity was recorded.
- Type — the kind of activity. The available types depend on the engine and the runtime data it exposes.
- Object — the database object involved, when one applies.
- User — the database user associated with the activity.
- Status — the outcome, shown as a badge.
- Duration — how long the activity took.
The list can be searched, filtered per column, and paginated.
How it's calculated
- Rows come from the runtime activity the agent collects for this database in the selected window, most recent first.
Reading it
Use it as the "what just happened here?" feed. When a metric tile above spikes, the matching timestamps in this table usually name the operation responsible. Filtering by user or object turns it into a quick answer for "who touched this table recently" — for a permanent, security-oriented record, Audit Logs is the right surface; this list is operational and scoped to the selected window.