Section 1 of 3 · 6 minutes
Monitor service outcomes first
Your goal
What you will be able to do
Choose signals that describe availability, latency, errors, and resource pressure for users.
Why this matters at work
The practical reason
A large dashboard can still miss the few changes that predict user impact.
Learn
The idea in plain English
Begin with the service outcome: can clients connect, finish important queries, and commit work within the expected time? Then add PostgreSQL signals that explain changes in that outcome.
Use rates and percentiles where totals hide timing. Separate workload growth from failure signals. A high transaction count can be healthy; a rising error or wait rate needs investigation.
Remember these points
- Start with user-visible availability and latency.
- Add database signals that explain those outcomes.
- Prefer trends and rates to unbounded cumulative totals.
See it in SQL
Read database activity totals
Collect transaction, session, and temporary-file counters with their observation window.
SELECT
datname AS database_name,
numbackends AS current_connections,
xact_commit,
xact_rollback,
temp_files,
stats_reset
FROM pg_stat_database
WHERE datname = current_database();Most fields are cumulative since `stats_reset`. Store two samples and divide the difference by elapsed time to calculate a rate.
`numbackends` is current rather than cumulative, so interpret each field according to its meaning.
Current connections and cumulative transaction and temporary-file counters for the current database, including reset time.
Useful words
Important terms
- Baseline
- A measured range that describes normal behaviour for a specific service and time period.
Quick check · Not graded
Check your understanding
Why must a cumulative counter include its reset time?
Your progress is saved to your signed-in account.