Know your database answers before your app finds out.
A web check tells you the homepage loads. It does not tell you the database behind it accepts logins, answers queries in time and still has the data you expect. m0nitor connects to MySQL, MariaDB, PostgreSQL and Redis like your application does.
Real logins: Connect and authenticate with a monitoring user, so a rejected login or a full connection pool shows up as what it is.
Test queries: Run a query such as SELECT 1 or a count, and compare the result: equals, contains, at most or at least a number.
TLS and encrypted secrets: Use TLS with certificate verification. Passwords and certificates are stored encrypted.
Private databases: Databases without a public port are checked by a probe you run inside your network.
What a database check catches
The server is down or does not accept connections
Authentication fails after a password rotation or a permission change
Queries are slow, measured as connection and query latency
A query returns an unexpected result, for example an empty table after a failed import
Redis answers but rejects commands, for example when it runs out of memory
Built for least privilege
Create a dedicated monitoring user with read access to the one table or view your test query needs. m0nitor never needs write access, and the credentials are stored encrypted and only used by the probes that run the check.
Set up in three steps
Create a monitoring user: Give it permission to log in and read what your test query touches, nothing more.
Add a database monitor: Pick MySQL/MariaDB, PostgreSQL or Redis, enter host, port and credentials, and optionally a query with an expected value.
Choose the probes: Use hosted probes for public databases or your own probe for private networks.
Plan availability
Database monitors are part of the Scale, Business and Enterprise plans. Checking private networks through your own probe needs Business or Enterprise.