MySQL often sits at the center of revenue-critical workflows: orders, logins, billing, inventory, and background jobs. When something changes unexpectedly—replication starts lagging, error rates jump, disk fills up, or a queue stops draining—you don’t need more dashboards. You need MySQL monitoring notifications that are accurate, timely, and quiet until they truly matter.
This guide explains how to design reliable notifications using read-only SQL checks, good thresholds, and low-noise patterns that work whether you’re monitoring a single MySQL instance or a fleet behind proxies and read replicas.
What “good” MySQL monitoring notifications look like
Before writing queries, define what success means. Effective notifications share these traits:
- Actionable: the alert tells you what changed and what to do next.
- Low-noise: alerts don’t repeat every minute while you’re already responding.
- Measured: thresholds reflect business impact, not curiosity.
- Safe: checks are read-only and do not add load or lock hot tables.
- Secure: credentials are scoped, encrypted in transit, and auditable.
Most teams struggle not because they lack metrics, but because they lack alert design. The rest of this post focuses on patterns you can implement with SQL alone.
Core alerting patterns (and when to use each)
Nearly all mysql monitoring notifications fall into a small set of patterns. Choose based on what you’re monitoring and how noisy the signal is.
| Pattern | Best for | Noise risk | SQL idea |
|---|---|---|---|
| Threshold | Lag, disk, error counts, backlog | Medium | value > X or value < Y |
| Delta / rate | Spikes (errors/min), sudden drop in orders | Medium-High | Compare “now” vs “N minutes ago” |
| State change | Job stuck → running, enabled → disabled | Low | Notify only when status differs |
| Absence | No new rows, no payments, no heartbeats | Low-Medium | MAX(created_at) < NOW() - INTERVAL ... |
| Top-N / outliers | Slow queries, largest tables, hottest tenants | High | ORDER BY ... DESC LIMIT N |
Rule of thumb: alert on impact, not on “interesting.” If you can’t write down the runbook action, you probably shouldn’t page on it.
Five practical MySQL checks you can turn into notifications
Below are common checks you can run on a schedule (every minute, five minutes, etc.). They’re written to be read-only and to avoid scanning large application tables where possible.
1) Replication lag (replica health)
If you use replicas for reads, backups, or analytics, replication lag is a frequent cause of “data looks wrong” incidents. How you query lag depends on your MySQL version and replication method, but this classic check is still widely used.
-- On a replica
SHOW SLAVE STATUS;From the result, alert when Seconds_Behind_Master exceeds a threshold (e.g., 60s for user-facing reads; higher for batch analytics). Also alert if replication is broken:
Slave_IO_Running != 'Yes'Slave_SQL_Running != 'Yes'Last_SQL_Erroris non-empty
Noise reducer: require the lag to exceed the threshold for two consecutive checks before notifying.
2) Connection pressure (too many sessions)
Connection storms can cascade into timeouts and thread exhaustion. Monitor how close you are to max_connections and whether the spike persists.
SELECT
(SELECT VARIABLE_VALUE FROM performance_schema.global_variables
WHERE VARIABLE_NAME = 'MAX_CONNECTIONS') AS max_conn,
(SELECT VARIABLE_VALUE FROM performance_schema.global_status
WHERE VARIABLE_NAME = 'THREADS_CONNECTED') AS threads_connected;Alert if threads_connected / max_conn exceeds, say, 0.85 for more than one interval.
Noise reducer: notify only when the ratio crosses the boundary (state change), not on every subsequent check.
3) Locking / long transactions (user-visible slowdowns)
Long-running transactions and metadata locks often show up as “the app is slow” before CPU and memory graphs look alarming. Use information_schema and performance_schema to spot trouble.
-- Long-running queries (tune the time threshold)
SELECT
ID, USER, HOST, DB, COMMAND, TIME, STATE,
LEFT(INFO, 200) AS sample
FROM information_schema.PROCESSLIST
WHERE COMMAND != 'Sleep'
AND TIME >= 60
ORDER BY TIME DESC
LIMIT 10;Alert when you see multiple queries running longer than your SLO (for example, 60s), or when a specific state indicates blocking (e.g., “Waiting for table metadata lock”).
Noise reducer: alert only if count ≥ N (e.g., 5+ long-running queries) to avoid pinging on one-off admin queries.
4) Error rate from your own app logs table (business-impacting)
If you persist structured application errors into a MySQL table, you can alert on error rate spikes using a time window. This can be more actionable than generic server metrics because it directly maps to user impact.
-- Example schema: app_errors(id, created_at, severity, code)
SELECT
COUNT(*) AS errors_last_5m
FROM app_errors
WHERE created_at >= NOW() - INTERVAL 5 MINUTE
AND severity IN ('ERROR', 'CRITICAL');Alert when errors_last_5m exceeds a baseline (static threshold) or when it jumps vs. the prior window (delta). If you can, segment by code:
SELECT code, COUNT(*) AS cnt
FROM app_errors
WHERE created_at >= NOW() - INTERVAL 5 MINUTE
GROUP BY code
ORDER BY cnt DESC
LIMIT 5;Noise reducer: notify on the top offending code(s), not the full list. Keep payload small.
5) “Absence” alerts: nothing happened when it should
Some of the most valuable mysql monitoring notifications are absence checks: no new orders, no heartbeats from workers, no events processed. These catch silent failures.
-- Example: no successful payments in 15 minutes
SELECT
MAX(paid_at) AS last_payment
FROM payments
WHERE status = 'SUCCESS';Trigger an alert if last_payment is older than your tolerance (e.g., 15 minutes during business hours). A more targeted check can watch a worker heartbeat table:
SELECT worker_id, MAX(heartbeat_at) AS last_seen
FROM worker_heartbeats
GROUP BY worker_id
HAVING last_seen < NOW() - INTERVAL 2 MINUTE;Scheduling: choosing an interval that won’t bite you
How often should you run checks? The right answer depends on detection goals and cost. Use this as a starting point:
- 1 minute: replication breakage, queue stuck, outage-level signals.
- 5 minutes: error spikes, rising connection pressure, slow query surges.
- 15–60 minutes: capacity growth (table size, disk usage), compliance checks.
Whatever interval you choose, treat it as part of the contract: shorter intervals create faster detection but more database load and more repeated notifications unless you add deduplication logic.
Reducing alert fatigue: three techniques that work
1) Add hysteresis (separate “on” and “off” thresholds)
Instead of alerting at a single boundary (e.g., lag > 60s), use two thresholds:
- Alert ON: lag > 60s
- Alert OFF: lag < 30s
This prevents flapping when values hover near the limit.
2) Require persistence (N-of-M checks)
For spiky metrics, alert only if the condition is true multiple times:
- True in 2 consecutive runs, or
- True in 3 of the last 5 runs
This dramatically improves signal quality for rate-based checks.
3) Notify on state change, not continuous state
If a system is already “in incident,” repeated alerts are rarely helpful. Prefer logic like “notify when crossing into bad” and “notify when recovered.” This is the single easiest way to make mysql monitoring notifications feel calm instead of chaotic.
Security and safety: don’t trade monitoring for risk
Monitoring is production access. Treat it like production code.
Use a dedicated read-only MySQL user
Create a user with the minimum privileges needed for your checks (often SELECT on specific schemas, plus access to performance_schema / information_schema where required). Avoid SUPER and broad grants.
-- Example (adjust schemas/tables to your needs)
CREATE USER 'monitor_ro'@'%' IDENTIFIED BY 'strong-password';
GRANT SELECT ON your_app_db.* TO 'monitor_ro'@'%';
GRANT SELECT ON performance_schema.* TO 'monitor_ro'@'%';
GRANT SELECT ON information_schema.* TO 'monitor_ro'@'%';
FLUSH PRIVILEGES;Encrypt connections and restrict network access
- Require TLS for database connections when possible.
- Allowlist monitoring IPs (or use a VPN/private network).
- Rotate credentials and audit access.
Keep queries lightweight
For checks that hit application tables, ensure indexes support the filter (e.g., created_at, status). A monitoring query that scans a billion-row table every minute is its own incident.
Delivery: email vs push vs chat (choosing the right channel)
Your notification channel affects response time and noise tolerance:
- Push notifications: best for urgent, time-sensitive alerts (replication broken, backlog stuck).
- Email: best for summaries, low urgency, and auditability.
- Chat (Slack/Teams): best for team visibility and collaborative incidents.
If you can only pick one for critical issues, choose the channel people see immediately, and reserve email for rollups and “FYI” alerts.
A simple checklist for implementing MySQL monitoring notifications
- Define the outcome: what action should be taken when the alert fires?
- Pick a pattern: threshold, delta, state change, absence.
- Write a read-only query: small result set, indexed predicates.
- Add noise controls: hysteresis, persistence, dedupe.
- Secure access: least privilege, TLS, restricted networking.
- Test failure modes: simulate lag, stop a worker, force an error spike.
Closing thought
When done well, mysql monitoring notifications aren’t “more alerts”—they’re an early-warning system that lets you respond before customers notice. Start with a handful of high-signal checks (replication health, connection pressure, absence of critical events), refine thresholds over time, and make every notification carry a clear next step.
If you prefer running scheduled read-only queries and receiving push/email notifications on mobile, an iOS approach like Query Alert can fit neatly into this pattern without changing your database architecture.