Set up database alerts that fire before anything breaks

Published 2026-09-02

Monitoring that you have to remember to look at is not monitoring. The point of an alert is that it reaches you when you are not thinking about the server at all; and the failures worth alerting on are rarely the ones a dashboard makes obvious.

The failures that matter

Ranked roughly by how often they take something down without warning:

• The service stopped. Obvious, and still the most common. A database that is not running produces no metrics, which is why a monitoring system that only charts numbers can show a reassuring flat line while everything is down.
• Connections exhausted. The server is fine; it simply cannot accept another client. Applications report this as a connection error, so it is often misdiagnosed as a network problem.
• Disk filling. Databases die badly when they run out of room, and the write that fails is usually a transaction log. This one is entirely predictable and therefore inexcusable to be surprised by.
• Backups silently failing. The worst category, because nothing is visibly wrong until the day you need the backup.
• Replication lag. Reads start returning stale data long before anything errors.

Wiring it up

Add the host in Fleet, point Database Health at it, and the checks run on a schedule. Failures raise entries in Alerts, which is also where delivery is configured; so a check that fires actually reaches you rather than sitting in a pane you are not looking at.

Delivery matters more than people expect. An alert that only appears in the app is an alert you will see when you next open the app, which may be Monday. Alerts can reach you by notification, email or a chat channel; the Slack integration puts server alerts in the room where your team is already talking, and can hand a problem to the AI Administrator from the same thread.

Test it deliberately

An untested alert path is a guess. Stop the database on a staging host and confirm the alert arrives where you expect. Alert delivery failures are themselves tracked; a badge appears when a channel stops accepting messages; because an alerting system that cannot deliver is worse than none at all: it produces false confidence.

Then let the assistant take the first look

When an alert does fire, the AI Administrator can do the initial triage: read the process list, check the settings, look at the logs, and tell you what it found. Read-only unless you approve otherwise; so it can investigate at 3am without changing anything you have not agreed to.

Where this lives in the app

Databases ▸ Database Health is the pane doing the work. Pick a target, and it lists every live connection, flags the ones worth worrying about, and; for MySQL and PostgreSQL; answers "why is this slow or stuck?" against the running server rather than guessing from a log.

Nothing here needs an agent installed on the database host. FrontierStack reaches a linked server over SSH using the key you already use, and reads through the database's own admin interfaces.

Set the alert before you need it

The useful moment for monitoring is the one before something breaks. Add the host in Fleet, point Database Health at it, and let the checks run on a schedule; a dead database reads as "no data", not "no problem", so an explicit alert is what turns a silent failure into a notification you actually receive.