It’s 3 AM. Your app is down. Why? Because your Postgres database hit its max_connections limit, and you didn’t know until the customer support tickets started rolling in. We’ve all been there, staring at a dashboard that shows 50 different metrics, none of which actually warned us the database was suffocating.
The observability industry has conditioned us to believe that if a dashboard doesn’t require a PhD to read, it isn’t doing its job. The dogma says you need a massive observability stack to catch database connection pressure. You need an agent, a time-series database, a custom query language, and a SaaS bill that rivals your cloud compute costs. It’s a lie.
Complexity is the enemy of reliability. When your monitoring tool requires more resources than the thing it monitors, you’ve already lost.
Enter pgwd (Postgres Watch Dog). It’s a tiny Go CLI built by a developer who got sick of the bloat. It polls pg_stat_activity, counts your total, active, idle, and stale connections against your max_connections limit, and then—it does the unthinkable. It just exits.
Cron and Kubernetes Jobs have natively understood exit codes since the dawn of Unix. If pgwd detects connection saturation, it exits with a non-zero code. Cron sees the failure and triggers the alert. That’s it. It can push to Slack, PagerDuty, Teams, or a webhook, without a daemon running 24/7 in the background eating your CPU.
The best infrastructure is the infrastructure you don’t have to maintain. A cron job never needs a security patch.
Think about what this means for small teams and lean deployments. You don’t need to spin up a Prometheus instance just to know if your database is choking. You don’t need to onboard onto another enterprise platform just to get a Slack ping when your idle connections are piling up. You get relief from the dread of silent failures without adding operational complexity.
The next time you feel the anxiety of a silent database failure creeping in, resist the urge to install a 500MB observability agent. Grab a single Go binary, set your cron schedule, and let the operating system do what it does best. Stop worshipping at the altar of complex dashboards. Embrace the exit code.
FAQ
Q: What if I need historical data and trend analysis, not just real-time alerts?
A: Then go buy your expensive SaaS dashboard. pgwd is for catching the knife before it falls, not writing a thesis on historical blade trajectories. If you need a time-series database, use one. If you just need to know your DB is about to crash, use a cron job.
Q: How exactly does a cron exit code trigger a Slack alert?
A: You configure your cron job to run pgwd. If it exits with a non-zero status (meaning it found connection pressure), your shell script or K8s job catches that exit code and fires off a webhook to Slack, PagerDuty, or Teams. It's basic Unix philosophy.
Q: Are you saying observability stacks like Datadog are useless?
A: Not useless, just massively overprescribed. They are vital for distributed systems with hundreds of microservices. But for a small team running a lean Postgres deployment, bolting on a heavyweight monitoring daemon is an anti-pattern. You're adding operational complexity to solve a problem a 10-line bash script can handle.