-
Database
Set up basic database monitoring
Adds visibility into connections, slow queries, disk growth, and locks with alerts before they become outages.
Free Prompt
Set up monitoring for my database so problems surface before users report them. Check what my host or database already exposes (managed databases have dashboards and metrics APIs; self-hosted needs a small amount of wiring) and build on that.
Cover the signals that actually predict outages: connection count approaching the limit, query latency (p95, not just average), slow query count, disk usage growth rate (project when it fills, don't just alert when it's full), replication lag if replicas exist, and lock wait time or deadlocks. Set alert thresholds that mean something: page-level for 'database down' and 'disk fills within days', email-level for 'connections trending up' and 'new slow queries appearing'. Store or snapshot the metrics somewhere they survive the database dying.
Use whatever monitoring already exists in my stack before adding new services. Don't alert on averages alone; a fast average with a terrible p95 is a broken app for some users. Don't set thresholds so tight they cry wolf.
Deliver: the metrics wired up, the alert thresholds with reasoning, and a runbook line per alert saying what to check first when it fires.
What This Does / How This Helps
Wires up the database metrics that predict outages: connections, latency percentiles, slow queries, disk growth, and locks, each with an alert threshold that means something. Database problems build quietly. Disk fills over weeks, connection counts creep with traffic, one deploy introduces a slow query. Without monitoring you find out from users; with it you find out from a chart with days of warning. The runbook line per alert is what makes the monitoring useful at 2am: the alert tells you what's wrong, the runbook tells you where to look first.
Want to skip doing this by hand?
Fortivibe audits your app for all of the areas these prompts cover (and more).