If you’re a database administrator wondering which database health metrics actually matter, you’re not alone. Most DBAs either monitor too many things and drown in noise, or track too few and miss the early signs of trouble. This guide covers the essential database health metrics every DBA should monitor — the ones that prevent 3 AM calls and keep your applications running smoothly.
I’ve seen environments where teams had 200+ alerts configured and ignored every single one of them. Alert fatigue is real. The trick isn’t monitoring everything — it’s monitoring the right things and knowing what each metric actually tells you.
Query Performance and Slow Query Logs
This is where most database problems first show up. If your queries are getting slower, something changed — a missing index, a growing table, a bad execution plan, or increased load.
Track your average query execution time and your 95th percentile response time. The average alone is misleading. You can have an average of 50ms while 5% of your users wait 4 seconds. That’s a problem hiding behind a good-looking number.
Set up slow query logging with a reasonable threshold. Start at 1 second and lower it as you clean things up. Review the slow query log weekly — not just when something breaks.
Connection Pool Utilization
Running out of database connections is one of those failures that looks bizarre from the application side. Users see random errors, timeouts, or partial page loads. Meanwhile, the server CPU looks fine.
Monitor your active connections versus your maximum allowed connections. If you’re consistently above 70% utilization, you’re one traffic spike away from a bad day.
Watch for connection leaks too. If active connections climb steadily over hours without dropping, something in your application layer isn’t releasing connections properly. This is more common than most people think, especially with ORM frameworks that manage connections behind the scenes.
Disk I/O and Storage Metrics
Databases live and die by disk performance. Monitor read and write latency, IOPS, and throughput. On spinning disks, anything above 20ms average latency is a concern. On SSDs, you should be well under 5ms.
Track disk space usage with projected growth. Don’t just alert at 90% full — that’s often too late. Alert at 75% and project when you’ll hit capacity based on the last 30 days of growth. I’ve seen a production PostgreSQL instance fill its disk at 2 AM because nobody noticed the WAL files were accumulating faster than archiving could keep up.
Also monitor your tablespace fragmentation. Heavily updated tables with lots of deletes can waste significant disk space and degrade scan performance over time.
Buffer Cache and Memory Usage
Your database’s buffer cache hit ratio tells you how often data is served from memory versus disk. For most OLTP workloads, you want this above 95%. Below 90% and you’re hitting disk way too often.
But here’s a myth worth busting: a high cache hit ratio doesn’t automatically mean your database is healthy. You can have a 99% hit ratio on a database that’s severely undersized for its workload — if the active dataset just happens to fit in memory. The moment your data grows or query patterns shift, performance falls off a cliff.
Monitor memory usage alongside cache ratios. Track how much memory the database process actually uses versus what’s available. Watch for swap usage — any significant swapping on a database server is an emergency, not a warning.
Replication Lag
If you’re running replicas — and you probably should be — replication lag is non-negotiable. Even a few seconds of lag can cause stale reads that lead to confused users, duplicate transactions, or data inconsistencies in your application.
Monitor lag in both time and bytes. Time-based lag tells you the user impact. Byte-based lag tells you whether you’re falling behind or catching up.
Set tight alert thresholds. For synchronous replication, any lag is abnormal. For asynchronous setups, define what your application can tolerate — usually under 5 seconds for read replicas serving live traffic.
Lock Contention and Deadlocks
Lock waits slow everything down silently. A single long-running transaction holding a table lock can cascade into dozens of queued queries. Users notice the slowdown, but the CPU and memory graphs look perfectly normal.
Monitor lock wait times and deadlock frequency. Occasional deadlocks are normal in busy systems — your application should retry them. But if deadlocks are increasing over time, something changed in your access patterns or schema.
Track long-running transactions specifically. Any transaction open longer than 5 minutes in an OLTP system deserves investigation. In many cases, it’s an admin running a manual query in a production console without realizing they left a transaction open.
Bringing It All Together with Real-Time Dashboards
Tracking these metrics individually is useful. Seeing them together on a single screen is where real operational awareness happens. When you can correlate a spike in query latency with increased disk I/O and a drop in cache hit ratio — all at the same time — you can diagnose problems in minutes instead of hours.
This is exactly why a centralized database performance monitoring approach matters. Jumping between five different tools to piece together what happened wastes critical time during incidents.
For the alerting side, focus on actionable real-time alerts rather than information dumps. Every alert should have a clear next step. If you get an alert and your first reaction is “so what?” — that alert needs to be deleted or reworked.
If your databases sit alongside web servers and application tiers, monitoring them in isolation gives you an incomplete picture. A multi-server dashboard that shows database metrics alongside server health helps you spot whether a database slowdown is the cause or the symptom.
FAQ
How often should I check database health metrics?
Your monitoring system should be collecting metrics continuously — every 30 to 60 seconds at minimum. For daily review, spend 5 minutes each morning looking at trends from the past 24 hours. Weekly, do a deeper review of slow queries, growth trends, and any metric that’s trending in the wrong direction.
Which single metric matters most for database health?
If you can only watch one thing, watch query response time at the 95th percentile. It’s the most direct measure of what your users actually experience. When this number moves, something meaningful changed — and it usually points you toward the root cause faster than any other metric.
Do I need paid tools to monitor database health properly?
No. Many essential database health metrics are available through built-in database commands and system views. What you need is a way to collect, visualize, and alert on them consistently. Free monitoring platforms can handle the full stack — from basic uptime checks to agent-based server and database metrics — without the licensing costs that enterprise tools charge per node.
The metrics listed here aren’t exhaustive, but they cover the areas where most real production problems originate. Start with these, tune your thresholds based on your actual baselines, and resist the temptation to add more alerts until you’ve acted on the ones you already have. Good monitoring isn’t about seeing everything — it’s about seeing the right things early enough to act.