Database health monitoring

Database health monitoring is a service with an initial setup and monthly operation: we connect collection of your DB metrics (MySQL/PostgreSQL etc.) and watch the key signals — availability and response time, slow queries, the number and exhaustion of connections, locks and deadlocks, replica lag, CPU/memory/disk usage, table and space growth. We configure dashboards and alerts on threshold breaches. This helps catch a problem on the approach (running out of space, slow queries piling up, a lock building) before the database starts to lag or goes down. Honestly about requirements: access to the DB metrics/server is needed (a monitoring account, sometimes an extension/agent); metric collection adds slight load, we tune a reasonable balance. Honestly about the essence: this is observation and alerting, NOT configuration, NOT optimization and NOT database administration — we do not rewrite queries, build indexes, tune the config or fix an outage; that is done by your developer/DBA or by us separately. Monitoring shows WHAT and WHERE is wrong and gives facts, but the specialist makes the decisions. Honestly about the method: some metrics are sampled at intervals, so very short spikes between samples can be smoothed/missed; rare one-off slow queries may also not fall into the sample. Thresholds need tuning — both false and missed alerts are possible; and an alert does not always arrive BEFORE a failure — some events are instant and visible after the fact. If metrics are collected through a third-party monitoring platform, its cost is separate. Coverage is the configured databases and metrics; someone must react to an alert. An important boundary: this is DB health monitoring, not database administration/optimization, not application APM (though it complements it — a slow query is visible there too) and not backup/recovery. If the database is tiny and there is almost no load, continuous monitoring may be overkill. Picture this: instead of 'the site went down at peak hour because database connections ran out and no one was watching' you get an alert about pool exhaustion in advance and have time to react. The base price starts from 12,000 ₽ per month; it depends on the number of databases and the metric set.

• The database periodically lags or goes down and you catch the cause after the fact.
• You do not know about slow queries, locks and replica lag in advance.
• Disk space or the connection pool runs out unexpectedly.
• There are no dashboards and alerts on the database state.

• Collection of key DB metrics (MySQL/PostgreSQL etc.)
• Availability, response time, slow queries
• Connections and their exhaustion, locks and deadlocks
• Replica lag, CPU/memory/disk, table and space growth
• Dashboards and alerts on threshold breaches
• A reasonable balance of detail and collection load
• Monthly operation of the monitoring
• An alert channel of your choice (email, messenger, webhook)

• You learn about a database problem on the approach, not when the site is down
• You see slow queries, locks, resource shortages
• You react earlier to running-out space and connections
• You have facts for the DBA/developer to remediate the bottleneck (the fix itself — separately)

• We clarify the DBMS, goals and metrics; collect access to the metrics/server
• We connect collection, configure dashboards, thresholds and alerts
• We launch operation, review findings on a call

• Will you optimize the database and fix an outage?

  No. We observe and notify, but we do not rewrite queries, build indexes, tune the config or fix an outage — that is done by your developer/DBA or by us separately. Monitoring shows what and where is wrong and gives facts for the decision.

• Is database access needed?

  Yes, access to the DB metrics/server is needed (a monitoring account, sometimes an extension or agent). Metric collection adds slight load — we tune a reasonable balance of detail and load.

• Will you catch any short spike?

  Not necessarily. Some metrics are sampled at intervals, so very short spikes between samples can be smoothed or missed, as can rare one-off slow queries. The more frequent the sampling, the lower the chance of missing one, but not 'everything down to the second'.