How to Monitor Database Servers Safely
Database monitoring needs a different approach than website monitoring. In most cases, your database should not be reachable from the public internet at all. If it is publicly reachable, nsmon can still check its TCP port. In practice, the stronger pattern is usually to keep the database private and expose a narrow HTTPS health endpoint that verifies the database connection and a simple query from inside your application environment.
What database monitoring should actually prove
An open TCP port only proves that something is listening on that port. It does not prove the database accepts connections, authenticates correctly, or can answer useful queries. This is why raw port monitoring is useful, but limited.
For production systems, it is usually safer to keep PostgreSQL, MySQL, or Redis off the public internet and validate them indirectly through your application or a dedicated internal health endpoint. That gives you a much stronger signal without weakening your security posture.
Common database monitoring scenarios
A database is intentionally exposed
If a database port is publicly reachable by design, a TCP port check can tell you whether the listener still accepts connections on ports like 5432, 3306, or 6379.
A database should remain private
In that case, you usually do not want internet probes touching the database directly. A safer pattern is to verify database health through your web application or a dedicated health endpoint.
You need a stronger signal than an open port
A small query such as `SELECT 1` or a metadata lookup proves more than basic reachability. It tells you the app can connect, authenticate, and get a real response back.
You want one monitor to cover the full path
An HTTPS health endpoint can prove that DNS, TLS, the web app, and the database dependency all work together from the user-facing entry point.
Recommended monitoring approach
Keep the database private when possible
For most production systems, direct public exposure of PostgreSQL, MySQL, or Redis is not a best practice. Restrict access at the network layer and avoid treating the database as a public endpoint.
Use a TCP port check only when direct exposure is intentional
If the database really is reachable from the internet, nsmon can verify that the TCP port still accepts connections.
Prefer an HTTPS health endpoint for real validation
Create a narrow endpoint that opens a database connection, runs a simple query, and returns a stable marker only when the dependency is healthy.
Match the response body in nsmon
Then use an HTTPS check with expected status and body match. That way you validate the app and the database together instead of watching only one raw port.
How to think about the monitoring layers
A practical database setup often ends up with two different kinds of checks:
Check 1 TCP 5432 reachable Optional direct reachability check Check 2 HTTPS /health/db -> 200 OK Application-level database validation Check 3 Body contains "db_ok" Stable success marker validation
TCP check
Useful when you intentionally expose a database port and want to know whether the listener is reachable from the internet.
HTTPS health check
Usually more valuable, because it proves the application can still talk to the database with real credentials and real network path assumptions.
Body match
A stable marker such as `db_ok` reduces ambiguity and avoids treating every `200 OK` page as success.
Combined monitoring
Using both layers gives you a clean way to separate port-level reachability from application-level database health.
Why raw port monitoring is not enough
A database process can still keep the port open while authentication is broken, the pool is exhausted, permissions are wrong, or a query path is failing. That is why a green TCP port alone should not be treated as proof that the database is healthy for real workloads.
The strongest signal usually comes from a small application-facing endpoint that performs a controlled query and returns an explicit success marker only when that query succeeds.
Direct TCP check vs HTTPS database health endpoint
| Topic | TCP port check | HTTPS health endpoint |
|---|---|---|
| What it proves | A listener accepts TCP connections on the target port. | The app can reach the database, authenticate, run a query, and return a valid response. |
| Security posture | Requires a publicly reachable database port if used from public probes. | Lets the database stay private while monitoring still validates the dependency. |
| Troubleshooting depth | Lower. Good for basic reachability only. | Higher. Better reflects the real application path. |
Website monitoring best practices turn one endpoint into a stronger signal.
If you expose a database health endpoint over HTTPS, combine it with expected status and body match so you validate more than a single port.
Read website monitoring best practices βExamples from real setups
PostgreSQL behind the app
The safest pattern is often an HTTPS endpoint that performs `SELECT 1` and returns `db_ok` only when the query succeeds.
MySQL for a legacy service
If the port is intentionally reachable, a TCP check on 3306 gives you basic reachability while an app-level endpoint gives deeper assurance.
Redis used as a critical dependency
A narrow application endpoint can confirm the app can still read or write a lightweight key instead of exposing Redis directly.
Admin forgets that the port is not enough
The port stays green, but the app fails because credentials, migrations, or permissions broke. This is exactly where the HTTPS health endpoint adds value.
Important limitations
- β A TCP port check cannot prove that authentication, permissions, or actual SQL queries are healthy.
- β Publicly exposing a database only for monitoring is usually not a good security tradeoff.
- β A health endpoint should stay narrow and stable so monitoring does not become a heavy synthetic workload.
- β The response should expose only a safe success marker, not internal database details.
Common manual checks
nc -vz db.example.com 5432 Shows whether the PostgreSQL listener is reachable from your current network path.
nc -vz db.example.com 3306 A quick way to test basic MySQL port reachability.
curl -fsS https://app.example.com/health/db Closer to the real production path because it validates the app and the database together.
Minimal health endpoint examples
<?php
$pdo = new PDO(getenv('DB_DSN'), getenv('DB_USER'), getenv('DB_PASS'));
$stmt = $pdo->query('SELECT 1');
if ($stmt && $stmt->fetchColumn() == 1) {
header('Content-Type: text/plain');
echo 'db_ok';
exit;
}
http_response_code(503);
echo 'db_fail';Keep the response intentionally small. nsmon can check for HTTP 200 and a body marker such as `db_ok`.
from flask import Flask, Response
import os
import psycopg
app = Flask(__name__)
@app.get("/health/db")
def db_health():
with psycopg.connect(os.environ["DATABASE_URL"]) as conn:
with conn.cursor() as cur:
cur.execute("SELECT 1")
ok = cur.fetchone()[0] == 1
return Response("db_ok" if ok else "db_fail", status=200 if ok else 503, mimetype="text/plain")The same idea works for other frameworks: connect, run a lightweight query, return a stable marker, and avoid leaking internals.
Frequently asked questions
Monitor databases in a way that matches production reality.
Use nsmon to watch public TCP ports when needed, or validate the stronger path through an HTTPS health endpoint that confirms your application can still talk to the database. Create a free account and build monitoring that is both safer and more useful.