Your Whole Database Tier, From the Agent You Already Installed

The usual way to monitor a database is to run something next to it - postgres_exporter, mysqld_exporter, redis_exporter - point a scraper at each one, then build the dashboards yourself. That is three more processes to install, keep upgraded and monitor in their own right, before you have seen a single metric.

Fivenines reads each engine over the interface it already exposes: the pg_stat_* views for PostgreSQL, SHOW GLOBAL STATUS for MySQL and MariaDB, INFO for Redis and Valkey, and a single stats command over TCP for Memcached. You flip a toggle, give it credentials where the engine needs them, and the metrics land next to the CPU and disk figures for the same box.

All four collectors run on Linux, Windows and macOS, so the same toggle works wherever the engine does.

PostgreSQL and MySQL report a three-state verdict rather than a boolean. Reachable means connected and collecting. Unreachable means refused, timed out or unroutable - the network-shaped failure, and the one worth paging on. A config error means the server answered and then rejected the agent: a wrong password, a role missing a grant. That last one is the common case after a credential rotation, and calling it an outage would send someone hunting a problem that is a two-field fix in Settings.

Redis and Memcached are deliberately simpler. They report metrics and nothing else, so a failed collection leaves a gap in the charts rather than a verdict - which is the honest representation when the agent has nothing to say. Put thresholds on their metrics to catch a cache under pressure, and be aware that a threshold reads a value: it will not fire for a cache that has stopped answering at all, because there is no value to read. For that, watch the port or the systemd unit - both are triggers in the same workflow builder.

PostgreSQL, MySQL and Memcached each take a host and a port, so the agent can watch a container's published port, a database on another machine, or a managed instance. Redis and Valkey are the exception: the agent polls a port on the machine it runs on.

Three alerts ship as one-click workflow templates: PostgreSQL unreachable, MySQL unreachable, and a degraded Galera cluster. Each opens one incident for the instance it is about and closes it on its own when the condition clears.

The Galera one is the interesting one. It fires while the cluster is anything other than Primary, while the local node is anything other than Synced, or - if you tell it how many members to expect - while the cluster is short a member. If the server becomes unreachable it hands off to the MySQL alert rather than firing a second time about a cluster it can no longer see, so a dead node pages you once.

Everything else is a metric threshold, on any of the 62 series: Redis memory closing on maxmemory, a hit ratio collapsing, replication lag climbing, Memcached evicting under pressure. The same sustained-duration rules, escalation gates and maintenance windows apply as to any other alert. Thresholds answer "this is going wrong"; for "this stopped answering" on Redis or Memcached, add a port or systemd-unit trigger, since a threshold needs a value to compare.

Alerts go where your team works: email, Slack, Microsoft Teams, Telegram, Discord, Pushover, PagerDuty or webhooks. Which of those you can use depends on your plan - email, Telegram and Discord are on every plan, and the rest unlock as you move up.