Database activity monitoring: How to automatically monitor and set alerts for a database

TL;DR

• Database activity monitoring (DAM) tracks queries, user behavior, security events, and infrastructure metrics in real time — not just whether the database is “up.”
• Effective DAM combines performance monitoring with security and compliance auditing, so you know both how the system is running and who is doing what inside it.
• Setting smart, tiered alerts matters more than setting many alerts. Alert fatigue is a real failure mode that causes teams to miss the incidents that count.
• Implementation follows a clear sequence: audit your environment, establish baselines, configure essential alerts, then layer in advanced features like anomaly detection.
• Automation tools like n8n can wire together metric collection, anomaly detection logic, and multi-channel alerting without requiring a full-time database administrator.

---

What Database Activity Monitoring Actually Means

Database activity monitoring is the continuous observation of everything happening inside a database system: queries being executed, users logging in and out, schema changes, failed authentication attempts, resource consumption, and data access patterns. It is not a periodic health check. It runs constantly, and it captures events in real time.

Traditional database monitoring tends to focus narrowly on whether the system is up and how fast queries are running. DAM is broader. It asks: who accessed what data, when, and why does that pattern look different from yesterday? That distinction matters for security teams, compliance teams, and anyone responsible for keeping a production database reliable.

Modern DAM implementations increasingly use statistical baselines and lightweight anomaly detection to separate genuine problems from background noise. The goal is not to generate more alerts — it is to surface the right signal at the right time.

---

What You Should Actually Be Monitoring

Getting DAM right starts with knowing what to track. There are three distinct layers, and teams that skip one of them tend to regret it.

Performance Metrics

These are the metrics most teams start with, and they remain essential:

• Query execution times — average, median, and worst-case response times per query type
• Slow query identification — queries running beyond an acceptable threshold (often 2-5 seconds in production)
• Lock contention and deadlocks — how often queries are blocked waiting for other transactions
• Connection pool utilization — how close you are to your connection ceiling
• Resource usage — CPU, memory, disk I/O, and network throughput at the database server level
• Buffer and cache hit ratios — how often the database reads from memory versus disk
• Storage growth rate — how quickly your data is growing and when you will need to plan for expansion

Security Events

This layer is where many SMB teams have gaps. Performance problems are visible. Security events often are not.

• Failed authentication attempts, especially in clusters or from unusual IP ranges
• Privilege escalation — when a user account suddenly has access it did not have before
• Off-hours data access that deviates from established user patterns
• Large bulk exports or SELECT statements touching sensitive tables
• Schema changes executed outside of normal maintenance windows
• New user accounts created directly at the database level, bypassing your application layer

Compliance and Audit Events

If your business operates under GDPR, HIPAA, or similar frameworks, you need a timestamped, tamper-evident record of who accessed what data and when. This is not optional. Automated DAM handles this continuously; manual processes do not.

• Data access logs per table and per user
• Change history for schema modifications
• Record of privilege grants and revocations
• Backup execution and restore events

---

How to Structure Your Monitoring Implementation

Step 1: Audit Your Environment Before You Configure Anything

A monitoring system configured without understanding the environment it is watching will generate noisy, misleading alerts from day one. Before you touch a monitoring tool, document:

• Every database instance in use (production, staging, development)
• The platform and version for each (PostgreSQL, MySQL, SQL Server, etc.)
• Where each database is hosted (on-premise, cloud, hybrid)
• Which applications depend on each database and what the business impact of downtime is
• Any existing monitoring tools, however informal

This inventory usually takes two or three days for a typical SMB environment. It is the most important step.

Step 2: Establish Baselines Before Setting Thresholds

Static thresholds — “alert if CPU exceeds 80%” — cause alert fatigue because they ignore context. A database that peaks at 90% CPU every Monday morning is behaving normally, not experiencing an incident.

Collect two to four weeks of data before configuring your alert thresholds. You want to understand:

• What peak load looks like versus off-peak
• Typical query volumes by hour and day
• Normal ranges for each metric you plan to alert on
• Any weekly or monthly patterns tied to business cycles

Modern monitoring tools can automate baseline calculation. Even so, review the results manually before activating alerts. Automated baselines can be fooled by anomalous data collected during the baselining window.

Step 3: Configure Tiered Alerts, Not a Flat List of Notifications

The most common DAM failure mode is not a gap in coverage — it is alert fatigue. When teams receive dozens of notifications daily, they start ignoring them. The incident that gets missed is usually buried in that noise.

Structure your alerts in three tiers:

Critical — requires immediate human response, any time of day or night:

• Database is unreachable
• Security event matching a high-risk pattern (bulk export at 2am, new admin account created outside change management)
• Disk at less than 5% free with writes still active

Warning — requires attention within hours, during business hours:

• Query response times trending 50% above baseline for more than 15 minutes
• Storage growth rate projecting exhaustion within 30 days
• Connection pool above 85% utilization

Informational — logged and visible in dashboards, no active notification:

• Schema changes executed during maintenance windows
• Routine backup completions
• Configuration changes applied by known admin accounts

A well-tuned alerting system for a typical SMB database environment should generate a handful of meaningful warnings per week, not per day.

Step 4: Route Alerts to the Right Channels

Different alert severities warrant different delivery mechanisms. Critical alerts should reach someone via SMS or a phone call, not just an email that might sit unread. Informational events belong in a Slack channel or a dashboard, not anyone’s inbox.

A simple routing structure:

• Critical: SMS + email + Slack, with escalation if unacknowledged after five minutes
• Warning: Email + Slack, no escalation unless unacknowledged for 30 minutes
• Informational: Slack channel only, no escalation

Automation tools like n8n make this routing straightforward to configure. You can write conditional logic that reads the severity field of an alert payload and dispatches it to the appropriate channel without any manual routing.

---

Building an Automated Monitoring Workflow with n8n

n8n is one of the tools Basalt Studio deploys for clients who need database monitoring workflows integrated with their existing communication stack. The underlying pattern is transferable to similar automation platforms.

A practical automated DAM workflow has two parts: a data collection loop and an alert processing loop.

Data Collection Loop

A scheduled trigger fires every 60 seconds and executes a set of monitoring queries against the database. For PostgreSQL, this might look like:

SELECT
    current_timestamp AS collection_time,
    (SELECT count(*) FROM pg_stat_activity WHERE state = 'active') AS active_connections,
    (SELECT count(*) FROM pg_locks WHERE granted = false) AS blocked_queries,
    (SELECT round(blks_hit::numeric / nullif(blks_hit + blks_read, 0) * 100, 2)
     FROM pg_stat_database WHERE datname = current_database()) AS buffer_hit_ratio;

The results are written to a time-series store or a lightweight monitoring database. Every 5 minutes, a second scheduled job queries storage capacity metrics. Every hour, a broader health check runs.

Alert Processing Loop

A separate workflow reads the collected metrics and compares them against dynamic thresholds derived from your baseline data. If a metric breaches a threshold, the workflow constructs an alert payload that includes:

• The metric name and current value
• The threshold that was breached and how the threshold was calculated
• The last known good value for context
• A suggested first action

The payload is then routed based on severity. In practice, this looks like a Switch node in n8n that reads the severity field and routes to the appropriate notification node — Twilio for SMS, Gmail or SendGrid for email, Slack for team channels.

Automated Remediation (where safe)

For a narrow set of well-understood issues, you can add an automated remediation step before the human notification. Killing a query that has been running for more than 30 minutes and consuming over 90% of CPU is a candidate. Clearing a stale connection from a pool is another. Be conservative here: automated remediation that fires incorrectly can cause more damage than the original issue.

---

Choosing Your Monitoring Tools

The right tooling depends on your environment, budget, and the level of operational sophistication your team can sustain.

Approach	Typical Use Case	Strengths	Considerations
Native database tools (pg_stat views, MySQL Performance Schema, SQL Server DMVs)	Single-platform environments with technical staff	Deep visibility, no additional cost	Requires SQL knowledge to interpret; no cross-system view
Open-source stack (Prometheus + Grafana)	Budget-conscious teams with a developer who will own the setup	Flexible, free, large community	Requires setup and ongoing maintenance
Cloud-native monitoring (AWS RDS Performance Insights, Azure SQL Analytics)	Databases already hosted on a major cloud provider	Tightly integrated, minimal setup	Tied to your cloud provider; limited for on-premise databases
Commercial platforms (SolarWinds DPA, Datadog, New Relic)	Teams wanting packaged solutions with support	Pre-built dashboards, ML anomaly detection	Higher cost; may be more than an SMB needs

For most founder-led SMBs with one to five production database instances, the open-source stack combined with cloud-native tools for hosted databases covers 90% of requirements at a fraction of the cost of enterprise platforms. Add a commercial alerting tool like PagerDuty only if your on-call rotation justifies it.

---

Common Mistakes That Undermine DAM Programs

Setting thresholds before establishing baselines. Static thresholds produce irrelevant alerts and teach teams to ignore the monitoring system. Always baseline first.

Monitoring without an owner. A monitoring system that nobody is responsible for maintaining will drift. Thresholds become stale, new databases get added without monitoring, and alerts start routing to old email addresses. Assign a named owner.

Ignoring security monitoring entirely. Many SMB teams configure performance dashboards and stop there. Security event monitoring — especially off-hours access, privilege changes, and bulk data exports — is where real business risk lives. It should be part of the initial implementation, not a phase-two project.

Skipping the test phase. Configure your alerts, then deliberately trigger them. Bring down a test database. Run a query that exceeds your slow query threshold. Verify that the right people receive the right notification through the right channel. Do this before you rely on the system for production incidents.

Tool sprawl without integration. Having separate tools for performance monitoring, security events, log aggregation, and alerting that do not talk to each other creates fragmented visibility. Prefer fewer tools with strong integration over many tools operating in isolation.

---

What Realistic Outcomes Look Like

Organizations that implement DAM properly — baselines before thresholds, tiered alerting, clear ownership — typically see measurable improvements within the first 60 to 90 days. McKinsey research on IT operations automation suggests productivity gains in the range of 20 to 40 percent for teams that automate routine operational tasks, and database monitoring is a canonical example.

More concretely, teams that previously spent several hours per week on manual database health checks find that those checks become unnecessary. The monitoring system surfaces issues before they are noticed operationally. Incident response time drops because on-call engineers receive a specific alert with context rather than discovering a problem through a user complaint.

Security posture improves partly because the capability to detect anomalous access now exists — and partly because knowing the capability exists changes behavior among internal users with database access.

The compliance benefit is often the most immediate: generating a complete audit trail automatically is straightforward with DAM in place, and doing it manually is extremely difficult.

---

Getting Started: A Practical Sequence

1. Week 1: Complete your database environment audit. Document every instance, platform, hosting environment, and dependent application.
2. Weeks 2-4: Deploy baseline monitoring using native tools or Prometheus + Grafana. Collect data without alerting.
3. Week 5: Define your alert tiers, configure thresholds based on your baselines, and set up notification routing.
4. Week 6: Test every alert type. Simulate failures. Fix whatever does not work.
5. Month 2 onward: Layer in anomaly detection, security event monitoring, and compliance logging. Tune thresholds monthly for the first six months.

This sequence is achievable without a dedicated database administrator. It requires someone with SQL familiarity, basic Linux or cloud console access, and a few hours per week during the setup phase.

---

Database activity monitoring is one of those investments that tends to be invisible when it is working and extremely visible when it is not. Getting the foundation right — good baselines, tiered alerts, clear ownership — removes most of the firefighting that consumes operational teams in SMB environments.

If you want to talk through how this applies to your specific database stack, Basalt Studio offers AI strategy calls focused on exactly this kind of operational automation. Book a free call here and we can look at what a practical monitoring setup would look like for your environment.