Databases
    Updated May 2026
    MongoDB logo

    MongoDB Monitoring

    Monitor MongoDB opcounters, WiredTiger cache fill / eviction, oplog window, replica-set lag, sharded balancer state, and slow queries in real time — via `db.serverStatus()` and `rs.status()`.

    Start Free TrialView Docs

    Why monitor MongoDB?

    MongoDB stores documents for Node.js apps, MEAN/MERN stacks, and modern SaaS. Replication lag, oplog window collapse, and WiredTiger cache pressure show up as 'sometimes slow' before they become full outages. Monitoring catches the underlying signals before clients fall back, elections trigger, or data goes silently stale.

    Auto-discovery via Xitogent — no manual configuration required
    Real-time document operation metrics (insert, update, delete, query)
    Replica set health and replication lag monitoring
    Connection pool usage and active connection tracking
    WiredTiger cache utilization and eviction metrics
    Storage size and index performance monitoring
    Works on both Linux and Windows servers
    1-minute metric collection intervals
    What is MongoDB monitoring?

    MongoDB monitoring, explained

    MongoDB monitoring catches replication lag, oplog-window collapse, WiredTiger cache pressure, and runaway queries before they cause replica failures, secondary fallback storms, or user-visible slowdowns. For MEAN/MERN stacks, sharded clusters, and any replica-set deployment, per-node visibility is what separates a graceful failover from a multi-hour incident. Xitoring auto-discovers your MongoDB, queries the native server-status commands with the clusterMonitor role, and routes alerts to Slack, PagerDuty, Telegram, or your existing on-call.

    Metrics

    What we monitor

    Document Operations

    Rate of insert, update, delete, and query operations per second.

    Connections

    Current active, available, and total connections to the MongoDB instance.

    Replication Lag

    Time delay between primary and secondary replica set members.

    Oplog Window

    Duration of operations retained in the oplog for replication.

    WiredTiger Cache

    Bytes currently in cache, dirty bytes, and cache hit ratio.

    Page Faults

    Number of page faults indicating data not in memory.

    Cursors

    Number of open cursors including those with no timeout.

    Network I/O

    Bytes in/out and number of requests to the MongoDB instance.

    Lock Queue

    Number of operations waiting to acquire read or write locks.

    Index Counters

    Index access, hits, and misses indicating index effectiveness.

    Storage Size

    Total data size, index size, and free space on disk.

    Assertions

    Count of assert messages including regular, warning, and rollover.

    Triggers & Alerts

    Configurable alert triggers

    Set up custom triggers in your dashboard to get notified the moment MongoDB metrics cross your defined thresholds.

    MongoDB monitoring trigger configuration dashboard

    Replication Lag

    critical

    Fires when secondary members fall behind the primary, risking data inconsistency during failover.

    Connection Count

    warning

    Triggers when active connections approach the maximum, indicating potential connection pool exhaustion.

    WiredTiger Cache Usage

    warning

    Alerts when cache utilization exceeds threshold, leading to increased disk I/O and slower queries.

    Page Faults

    critical

    Fires when page fault rate spikes, indicating working set exceeds available memory.

    Lock Queue Length

    warning

    Triggers when operations queue for locks, indicating contention and potential performance degradation.

    Storage Space

    critical

    Alerts when disk space usage exceeds threshold, risking database writes being blocked.

    01

    Importance of MongoDB Monitoring

    MongoDB powers mission-critical applications handling millions of documents. Without monitoring, replication drift, connection exhaustion, and cache pressure can silently degrade performance and lead to data loss.

    • Detect replication lag before failover causes data inconsistency
    • Monitor document operation rates to identify performance bottlenecks
    • Track WiredTiger cache efficiency to optimize memory allocation
    • Identify connection pool exhaustion from application clients
    • Ensure storage capacity for uninterrupted database operations
    MongoDB monitoring dashboard with document operations and replica set metrics
    MongoDB performance alerts and connection monitoring
    02

    Why Choose Xitoring

    Xitoring delivers enterprise-grade MongoDB monitoring with zero-config setup. Our lightweight agent auto-discovers your MongoDB instances, starts collecting metrics in under 60 seconds, and integrates with your existing notification channels.

    • One-command install — no complex YAML or config files
    • 15+ global monitoring nodes for low-latency checks
    • Unified dashboard for servers, databases, and uptime
    • Flexible alerting via Slack, PagerDuty, Telegram & more
    • Historical data retention for capacity planning & audits
    Xitoring MongoDB cluster monitoring overview
    Alert notification channels configuration
    Use cases

    Common MongoDB monitoring scenarios

    Where MongoDB typically runs today — and what could go wrong if no one's watching.

    Self-hosted database with backup copies

    Production setups run several copies of the database so a failure can't take the app down. When one copy quietly falls behind the others, the safety net is weaker than it looks. We catch the drift early so failover does what it's supposed to: stay invisible to users.

    Databases split across multiple servers

    When the data is too big for one server, it's split across many — but if some servers end up doing more work than others, the whole app slows down. We surface the imbalance so the team can rebalance the load before one overloaded server becomes a customer-facing problem.

    The database behind a Node.js app

    Most Node.js apps put a heavy load on MongoDB and reuse a pool of database connections to stay fast. When the app leaks connections or runs an inefficient query, every request slows down. We surface the cause quickly so the right team can fix it.

    Before you start

    Prerequisites for MongoDB

    Make sure you've got these in place — most installs are a 60-second job once they are.

    • MongoDB 7.0 LTS or 8.0 LTS (4.x and 5.x/6.x also supported) running on the server
    • A user with the clusterMonitor role (or readAnyDatabase + clusterMonitor for legacy versions)
    • Network reachability from Xitogent to every node you want to monitor (primary + secondaries + mongos + config servers for sharded clusters)
    Setup Guide

    Get started in minutes

    1

    Install Xitogent on your server

    If you haven't already, install the lightweight Xitogent monitoring agent on your server.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Create a monitoring user in MongoDB

    Create a dedicated MongoDB user with the `clusterMonitor` role so Xitogent can read serverStatus, replication state, and storage metrics:

    use admin db.createUser({ user: "xitogent", pwd: "xitogent!", roles: [{ role: "clusterMonitor", db: "admin" }] })
    3

    Enable the MongoDB integration

    Use the Xitoring dashboard or CLI to enable the MongoDB integration. Xitogent will auto-detect your MongoDB instance.

    sudo xitogent integrate
    4

    Configure alert thresholds (optional)

    Set custom thresholds for metrics like replication lag, connection count, or storage usage to get notified when something needs attention.

    5

    Verify it's working

    Run this command on the server to confirm Xitogent picked up the integration. Fresh metrics will start streaming to your dashboard within ~30 seconds.

    sudo xitogent status
    Compare

    Considering alternatives?

    See how Xitoring stacks up against the alternatives for MongoDB monitoring — flat pricing, deeper integrations, and one agent that covers your whole stack.

    See all comparisons

    Frequently asked questions

    What is MongoDB monitoring?
    MongoDB monitoring is the continuous collection of MongoDB performance data — opcounters (insert/query/update/delete/getmore/command), WiredTiger cache state, connection counts, replica-set `optimeDate` lag, oplog window, sharded balancer state, and slow queries from the database profiler — combined with alerting when those metrics breach thresholds. It surfaces the same data and Atlas show, with history and notifications layered on top.
    How do I monitor MongoDB replication lag?
    Run `rs.printSecondaryReplicationInfo()` on the primary, or query `rs.status()` for per-member `optimeDate` and compute the gap from primary. Xitogent does this automatically and exposes per-secondary lag in seconds. Alert when lag exceeds your RPO budget (typically a few seconds for production replica sets). MongoDB 8.0+ also surfaces `optimeWritten` for write-acknowledged-but-not-yet-applied state.
    What is the oplog window and why does it matter?
    The oplog window is the time span of operations currently retained in the oplog (capped collection on the primary). If a secondary's downtime exceeds the oplog window, it can't catch up by replaying — it needs a full initial sync, which can take hours on large data sets. Monitor `rs.printReplicationInfo` for current oplog window; alert when it drops below your maximum-expected-secondary-outage budget. Resize with `replSetResizeOplog`.
    How do I detect slow MongoDB queries?
    Enable the database profiler at level 1 (`db.setProfilingLevel(1, { slowms: 100 })`) — operations slower than `slowms` are logged to `system.profile`. Use `db.system.profile.find.sort({ts:-1})` for recent slow ops, or use `explain` on suspect queries. Xitogent surfaces the slow-query count per database from the profiler so you can trend regressions.
    How do I monitor WiredTiger cache hit ratio and eviction pressure?
    `db.serverStatus().wiredTiger.cache` exposes `bytes currently in the cache`, `tracked dirty bytes in the cache`, `pages evicted by application threads` (the bad kind — app threads doing eviction work), `pages currently held in the cache`, and `unmodified pages evicted`. Alert when cache fill exceeds 95% AND `pages evicted by application threads` is non-zero — that combination means cache pressure is impacting query latency.
    How do I monitor a MongoDB sharded cluster?
    Install Xitogent on the host (or hosts) running mongos routers AND on each shard's primary. Xitogent reads `sh.status()` for chunk distribution, balancer state, and config-server health. Per-shard `opcounters` distribution flags shard-key skew (one shard handling 80%+ of traffic = hot-shard problem). Monitor chunk migrations to catch balancer issues during high-write windows.
    What is mongostat used for?
    `mongostat` is the official MongoDB CLI for live operational stats (similar to `iostat` for disks). It shows per-second opcounter rates, network I/O, connections, queues, and the active dirty cache percentage in one rolling output. Xitogent surfaces the same metrics in long-term trends and alerts — `mongostat` is for live triage; Xitoring is for history, dashboards, and notifications.
    How do I monitor MongoDB Atlas vs self-hosted?
    For self-hosted, Xitogent runs alongside MongoDB and reads `serverStatus` directly. For Atlas, Atlas itself provides the Real-Time Performance Panel, Query Profiler, and built-in alerts via the Atlas Admin UI — Xitoring covers the network and endpoint side (uptime, response time, regional probes) to complement Atlas's database-internal metrics.
    What MongoDB versions are supported?
    MongoDB 7.0 LTS and 8.0 LTS (current default) are fully supported, plus older 4.x/5.x/6.x. Version 8.0 added `optimeWritten` for write-acknowledged replication state, queryable encryption range queries, `bulkWrite` across multiple collections, and time-series block processing — Xitogent surfaces the new metrics when present and falls back gracefully on older versions.

    Start monitoring MongoDB today

    Set up in under 60 seconds. No credit card required. Full metrics from day one.

    Start Free Trial

    Keep exploring

    Related Integrations