Database availability monitoring

Logdash cannot connect to a database itself, so you monitor database availability through something that can: an HTTP health route that runs select 1 and returns 503 when it fails, or a push monitor called by a script on a host next to the database.

Logdash does not open a connection to Postgres or MySQL. Monitors send HTTP GET requests from the public internet, there are no TCP port checks, and private addresses are refused. That sounds like a gap until you look at what a port check proves: that something accepted a TCP handshake on 5432. Not that your app can log in, not that the pool has a free connection, not that a query comes back.

Your database should not be reachable from the internet in the first place. So the check goes through something that already holds a connection, and there are two honest ways to do that.

Database uptime monitoring through your app

The best signal is a route in your app that runs the cheapest query the database can answer. It fails for the same reasons a user request fails: credentials rotated without a redeploy, an exhausted pool, a failover your DNS has not caught up with, a database that is simply gone.

health.js

import express from 'express';
import pg from 'pg';

// In a real app, import the pool your handlers use instead.
const pool = new pg.Pool({
  connectionString: process.env.DATABASE_URL,
  connectionTimeoutMillis: 2000, // no free connection in 2 s is a failure
  query_timeout: 2000,
});

const app = express();

app.get('/health/db', async (req, res) => {
  try {
    await pool.query('select 1');
    res.status(200).send('ok');
  } catch {
    res.status(503).send('db');
  }
});

app.listen(3000);

Use the pool the handlers use, or the check cannot see that pool running dry. MySQL is the same route with mysql2 and the same query. The 2-second timeouts matter: the Logdash pinger gives up after 10 seconds and records a timeout, but a hung pool should become a 503 you can read, not a timeout you have to guess at.

Postgres uptime monitoring from the database host

Some databases have no app in front of them: a reporting replica, a self-hosted Postgres on a VPS, a MySQL box only a nightly export touches. Run a small loop on that host, or one next to it, that queries the database and calls a push monitor when the query succeeds. Push monitors are on Pro and expect a call inside every 15-second window.

db-heartbeat.sh

#!/bin/sh
# Password from ~/.pgpass, -w never prompts for one.
# MySQL: mysql -h 127.0.0.1 -u app -e 'select 1' app
PING=https://api.logdash.io/ping/68b4c1f0e3a2d5c7b9f01234

while true; do
  psql -w -h 127.0.0.1 -U app -d app -tAc 'select 1' > /dev/null 2>&1 \
    && curl -fsS -m 5 -X POST "$PING" > /dev/null
  sleep 10
done

Query with the credentials your app uses. pg_isready exits 0 without a valid user or password, and mysqladmin ping exits 0 even on Access denied. Both prove the server process answers, which is less than you think you are checking.

Pick the path Public app in front of the database: ship the /health/db route. No app, or only a private network: run the heartbeat script under systemd, on Pro.
Create the monitor For the route, add a monitor with https://yourapp.com/health/db, checked every 5 minutes free, every minute on Builder, every 15 seconds on Pro. For the script, add a push monitor and paste its id.
Stop the database Connect Telegram and stop Postgres or MySQL. The route returns 503, or the pings stop, and a Telegram alert tells you the monitor is down.

MySQL uptime monitoring without code

Logdash vs Uptime Kuma

Feature	Logdash	Uptime Kuma
Connect to the database directly	No, through a health route or a push heartbeat	PostgreSQL, MySQL/MariaDB, SQL Server, MongoDB and Redis monitors
TCP port check	None	Yes
Reach a database on a private network	Only by push, from a host inside it, on Pro	Directly, when Kuma runs inside that network
Check the path your users take	A health route tests app, pool and database together	Same, with an HTTP monitor on the same route
Who watches the monitor	Hosted, outside your infrastructure	You run it, and on the database box it dies with the database
Alert channels	Telegram and webhook	Telegram, Discord, Slack, email and 90+ more

When Uptime Kuma is the better pick

You already run a box inside the network and want a database check without touching the app.
You need TCP port checks, or Redis and MongoDB monitors as well.
Self-hosting is a requirement. Uptime Kuma runs on your server today, and Logdash self-hosting is not a one-command install yet.

What is database availability monitoring?

Checking on a schedule that the database accepts connections and answers queries, and alerting when it stops. The useful version runs a real query with your app's credentials, because a server can accept TCP connections and still refuse your app.

How do I set up database uptime monitoring without exposing the database?

Keep the database private and check it through something that already reaches it: an HTTP route in your app that runs select 1, or a script on a nearby host that queries every 10 seconds and pings a push monitor on Pro after each success.

How does postgres uptime monitoring work in Logdash?

Through your app or a heartbeat. A /health/db route runs select 1 and returns 503 on failure, checked every 5 minutes free or every 15 seconds on Pro. Or psql in a loop on the host calls a push monitor on Pro. Logdash never connects to port 5432 itself.

Is mysql uptime monitoring any different?

Only in the driver. Use mysql2 in the route or the mysql client in the script, with the same select 1. Do not rely on mysqladmin ping, which exits 0 even when the server answers Access denied.

Database uptime monitoring through your app

Postgres uptime monitoring from the database host

MySQL uptime monitoring without code

Logdash vs Uptime Kuma

When Uptime Kuma is the better pick

Point it at your own URL and watch it for real.