How to monitor

How to monitor MongoDB

MongoDB backs a lot of apps — when it's unreachable or can't serve queries, everything above it fails. Here's how to monitor MongoDB reachability and health without exposing it.

StatusCat2 min read

MongoDB usually sits behind your app serving reads and writes. When it's unreachable, slow, or has lost its primary, the symptoms surface everywhere — failed requests, timeouts, stuck features — and it isn't always obvious the database is the cause. A direct check gives you a clear signal.

Here's how to monitor MongoDB reliably, without exposing it to the internet.

Two solid approaches

1. TCP reachability check (quick baseline)

A TCP check on MongoDB's port (default 27017) confirms it's reachable and accepting connections. This is useful when the database is on a publicly-reachable host. If MongoDB is private (as it usually should be), an external check can't reach it — use the heartbeat approach below instead.

2. Command heartbeat (stronger)

The best signal is a job that actually talks to MongoDB and reports health:

# Runs on a schedule inside your network
mongosh "$MONGO_URI" --quiet --eval 'db.runCommand({ ping: 1 }).ok' | grep -q 1 \
  && curl -fsS -m 10 https://statuscat.co/ping/your-mongo-heartbeat-id > /dev/null
  • The ping command proves the server can respond to queries.
  • The && means the ping only fires on success — so a failure becomes a missing heartbeat, and StatusCat alerts you.
  • Nothing is exposed publicly; the job reaches out.

For a replica set, connect to the set and confirm a primary is reachable — the heartbeat will stop if quorum is lost.

What else to watch

  • The app's use of MongoDB — a /health endpoint that runs a cheap query will fail if the database is unhealthy (how to monitor an API).
  • The database host — a TCP/ICMP check catches infrastructure-level failures.
  • Backups — a heartbeat on your backup job so a silent failure doesn't go unnoticed.
  • Replication & disk — emit these from inside and let a failing heartbeat page you when a threshold is crossed.

Put it together

A solid MongoDB setup is usually a command heartbeat ("can it serve queries / is there a primary?"), a TCP/host check ("is it reachable?"), and a backup heartbeat ("are we protected?"). Wire alerts and escalation so the right person hears about it fast.

StatusCat supports TCP, ICMP and heartbeat monitors alongside HTTP/DNS/SSL checks, free for 50 monitors. New to monitoring? Start with what uptime monitoring is.

Frequently asked questions

How do I monitor MongoDB without exposing it to the internet?
Keep it private and use a heartbeat: a small scheduled job inside your network runs a ping command (or a lightweight find) and pings StatusCat on success. If the check fails, the heartbeat stops and you're alerted.
Is a TCP check on port 27017 enough?
It's a useful baseline that confirms MongoDB is reachable, but a command-level heartbeat (db.runCommand({ ping: 1 })) is stronger because it proves the server can actually respond, not just accept connections.
What about replica sets?
For a replica set, check that a primary is electable and reachable. A heartbeat that connects and runs a ping (or reads from the primary) will fail if the set loses quorum, which is exactly when you want to be alerted.

Keep reading

GuidesHow to monitor SSL certificate expiry (and never get caught out)Expired TLS certificates cause instant, total outages — and they're completely preventable. Here's how certificate expiry monitoring works and how to set it up in minutes.GuidesHow to monitor an API (the right way)A 200 response doesn't mean your API works. Here's how to monitor an API properly — status, latency, payload correctness, auth and SSL — so you catch real failures before your customers do.GuidesHow to monitor a cron job (with heartbeats)Cron jobs fail silently — the job stops, the server reboots, a deploy breaks the schedule, and nobody notices until data is missing. Here's how heartbeat monitoring catches it.