Section 2 of 3 · 7 minutes
Set thresholds that lead to an action
Your goal
What you will be able to do
Connect each alert threshold to duration, user risk, and a first diagnostic step.
Why this matters at work
The practical reason
An alert without an owner or next action becomes noise and is eventually ignored.
Learn
The idea in plain English
A useful threshold considers magnitude and duration. One short connection spike may be harmless, while steady growth toward the limit needs action.
Write the first diagnostic query and escalation condition beside the alert. Test the alert with known data so the team sees the expected message before an incident.
Remember these points
- Combine threshold value with a meaningful duration.
- Name an owner and first diagnostic step.
- Review thresholds when workload or capacity changes.
See it in SQL
Calculate connection headroom
Show how many normal connection slots remain before the configured limit.
SELECT
current_setting('max_connections')::integer AS maximum_connections,
count(*) AS current_connections,
current_setting('max_connections')::integer - count(*) AS remaining_connections
FROM pg_stat_activity;The difference is a simple headroom signal. Reserved superuser or operator connections and pool limits also belong in the operational threshold.
Track the value over time rather than alerting on a single sample alone.
The configured maximum, current connection count, and simple remaining headroom.
Useful words
Important terms
- Headroom
- Capacity that remains before a service limit is reached.
Quick check · Not graded
Check your understanding
What makes an alert actionable?
Your progress is saved to your signed-in account.