MongoDB Monitoring and Observability

Parent: MongoDB Expert Knowledge · Published reference · snapshot 2026-09-08 · skill atlas-diagnostics-expert/references/mongodb-monitoring-observability.md

↓ Facts as markdown all context files

Comprehensive reference for monitoring MongoDB deployments — from Atlas built-in dashboards through third-party integrations, CLI tools, and low-level FTDC diagnostics.

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

MongoDB Monitoring and Observability

Comprehensive reference for monitoring MongoDB deployments - from Atlas built-in dashboards through third-party integrations, CLI tools, and low-level FTDC diagnostics. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#mongodb-monitoring-and-observability]
When to use this skill: When answering questions about Atlas metrics, alert configuration, third-party monitoring integrations (Datadog, New Relic, Prometheus), FTDC diagnostics, slow query analysis, replication lag, connection pool behavior, or Atlas maintenance windows and planned operations. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#mongodb-monitoring-and-observability]
When not to use: For Atlas Search index tuning (use mongodb-search-ai), Atlas cost optimization (use mongodb-cost-optimization), or backup/restore planning (use mongodb-backup-restore). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#mongodb-monitoring-and-observability]
Required roles for most monitoring operations: clusterMonitor role on the admin database (self-managed), or Atlas Project Read Only / Project Data Access Read Only (Atlas UI). Third-party integrations (Datadog, Prometheus, New Relic) require Atlas Project Owner or Organization Owner to configure. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#mongodb-monitoring-and-observability]
Jump to: Quick Reference Tool Matrix [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#mongodb-monitoring-and-observability]

1. Atlas Cloud Monitoring — Built-in Metrics and Dashboard Customization

Atlas provides real-time and historical metrics for every cluster tier M10 and above. Free/shared-tier clusters have reduced metric granularity (5-minute resolution vs. 1-minute for dedicated tiers). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#1-atlas-cloud-monitoring-built-in-metrics-and-dashboard-customization]

Key metric categories available in Atlas UI

Opcounters - insert, query, update, delete, getmore, command rates (ops/sec) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#key-metric-categories-available-in-atlas-ui]
CPU / System - process CPU, system CPU, I/O wait broken by read/write [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#key-metric-categories-available-in-atlas-ui]
Memory - resident, virtual, mapped, cache (WiredTiger block cache, dirty bytes) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#key-metric-categories-available-in-atlas-ui]
Disk I/O - IOPS read/write, I/O utilization, disk queue depth [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#key-metric-categories-available-in-atlas-ui]
Network - bytes in/out, number of requests [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#key-metric-categories-available-in-atlas-ui]
Connections - current, available, total created [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#key-metric-categories-available-in-atlas-ui]
Replication - oplog window hours, replication headroom, replication lag per secondary [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#key-metric-categories-available-in-atlas-ui]
Query targeting - scanned/returned ratio (key indicator of missing indexes) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#key-metric-categories-available-in-atlas-ui]
Tickets - WiredTiger concurrent read/write tickets in use vs. available [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#key-metric-categories-available-in-atlas-ui]

Dashboard customization

Atlas dashboards are pre-built per cluster but allow: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#dashboard-customization]
- Pin metric charts to a custom "Metrics" view for side-by-side comparison across nodes [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#dashboard-customization]
- Toggle between individual node view (per-host) and cluster aggregate view [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#dashboard-customization]
- Adjust time range (1h, 8h, 24h, 48h, 1w, custom) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#dashboard-customization]
- Use the Real-Time Performance Panel (RTPP) for 1-second granularity on live traffic - available on M10+ in the Atlas UI under the cluster's Real Time tab [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#dashboard-customization]
The RTPP shows: opcounters, read/write tickets, connections, network, logical size, and an interactive currentOp view showing the slowest in-flight operations per namespace. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#dashboard-customization]

2. Ops Manager and Cloud Manager — Self-Managed Deployments

> Deep reference: see mongodb-ops-manager for full coverage of App DB sizing/HA, Backup Daemon placement, automation goal-state, air-gap/Local Mode, Kubernetes Operator, federation, and Live Migration to Atlas. This section covers the monitoring agent surface only. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#2-ops-manager-and-cloud-manager-self-managed-deployments]
MongoDB Ops Manager is the on-premises deployment of MongoDB's management platform for teams running MongoDB in their own data centers or private clouds. MongoDB Cloud Manager is the hosted SaaS version of the same platform - it provides identical monitoring, automation, and backup capabilities without requiring you to host the Ops Manager application yourself. Both share the same agent architecture described below. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#2-ops-manager-and-cloud-manager-self-managed-deployments]

Monitoring agent behavior

Runs as a daemon alongside your MongoDB processes [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#monitoring-agent-behavior]
Polls serverStatus, replSetGetStatus, dbStats, collStats, currentOp (filtered) at configurable intervals [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#monitoring-agent-behavior]
Stores time-series data in Ops Manager's own MongoDB backing store (separate from your application data) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#monitoring-agent-behavior]
Sends alerts through Ops Manager's alert notification system - same alert types as Atlas [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#monitoring-agent-behavior]

Ops Manager / Cloud Manager dashboards

Both platforms replicate Atlas-style metric dashboards inside the web UI. The topology view shows replica set health, node states (PRIMARY/SECONDARY/ARBITER), and replication lag per member. The Hardware tab surfaces CPU, disk IOPS, and memory at host level for correlation with MongoDB behavior. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#ops-manager-cloud-manager-dashboards]

Alert scope levels

Project-level alerts - apply to all clusters in a project (e.g., CPU > 80% on any node) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#alert-scope-levels]
Cluster-level alerts - scoped to a specific cluster [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#alert-scope-levels]
Billing alerts - monthly spend thresholds, data transfer thresholds [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#alert-scope-levels]

Alert tuning best practices

Set delay intervals (e.g., "notify if condition persists for 5 minutes") to suppress transient spikes - CPU can spike briefly during flushes without being actionable [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#alert-tuning-best-practices]
CPU alert baseline: M10–M30 should alert at 75%; M50+ with sustained IOPS-heavy workloads often benefit from 85% thresholds with short delay [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#alert-tuning-best-practices]
Replication lag: alert at 10–15 seconds for most OLTP workloads; 60 seconds for batch-heavy pipelines [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#alert-tuning-best-practices]
Oplog window: never let it drop below 4 hours; alert at 48 hours to give time to investigate before backup windows are at risk [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#alert-tuning-best-practices]
Connection count: alert at 80% of the cluster's maxIncomingConnections; calculate max from db.adminCommand({getCmdLineOpts:1}) or Atlas connection string parameters [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#alert-tuning-best-practices]

Atlas Custom Metrics

Atlas supports custom metric alerts via the Atlas Administration API (/api/atlas/v2/groups/{groupId}/alertConfigs). The metricName field accepts any metric Atlas exposes - including metrics not shown by default in the UI. Full metric name catalog: https://www.mongodb.com/docs/atlas/reference/alert-conditions/ [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#atlas-custom-metrics]

$currentOp polling for application-level insight

For application-level custom metrics, poll $currentOp on a schedule. Note: run this query from an admin-context connection - the $all field was deprecated in MongoDB 4.0 and removed in favor of the admin-context currentOp command directly: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#currentop-polling-for-application-level-insight]
Key fields: secs_running, op, ns, planSummary, waitingForLock, msg, locks. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#currentop-polling-for-application-level-insight]

Application-level metrics to track

Query latency percentiles (p50, p95, p99) per collection [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#application-level-metrics-to-track]
Error rates by MongoDB error code [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#application-level-metrics-to-track]
Connection pool waitQueueSize - rising queue = pool exhaustion signal [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#application-level-metrics-to-track]
Retry attempt counts - spike in retries indicates transient elections or network partitions [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#application-level-metrics-to-track]

Setup

Atlas Datadog integration requires M10+ clusters and a Datadog API key. Configure via Atlas UI: Project → Integrations → Datadog. Select region (US1, US3, US5, EU1, AP1, US1_FED) to match your Datadog account region. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#setup]

Datadog Database Monitoring (DBM) for Atlas

Separate from the metrics integration - requires Datadog Agent with MongoDB integration. Provides query-level explain plan capture, wait event analysis, query normalization and fingerprinting. Configure via conf.d/mongo.d/conf.yaml with a clusterMonitor role user. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#datadog-database-monitoring-dbm-for-atlas]

6. New Relic Integration

Configure via Atlas UI: Project → Integrations → New Relic. Metrics ship under MongoDBAtlas.* namespace. Primary value: APM-to-database correlation - New Relic links slow transaction traces in application code directly to slow MongoDB operations when using the New Relic APM agent. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#6-new-relic-integration]
For self-managed MongoDB, use nri-mongodb with the New Relic Infrastructure agent (EXTENDED_METRICS: true, COLLECTION_METRICS: true). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#6-new-relic-integration]

Atlas managed endpoint (M10+ only)

Enable via Atlas UI: Project → Integrations → Prometheus. Scrape URL: https://cloud.mongodb.com/prometheus/v1.0/groups/{groupId}/metrics. Auth: HTTP Basic with Atlas programmatic API key pair. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#atlas-managed-endpoint-m10-only]

Self-managed Prometheus

Use mongodb_exporter (Percona) on port 9216. Search "MongoDB Overview Percona" in the Grafana dashboard library for a production-ready starting point. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#self-managed-prometheus]

8. FTDC (Full Time Diagnostic Capture)

FTDC is MongoDB's always-on internal diagnostic system (enabled by default since MongoDB 3.2). It is the first artifact MongoDB Support requests for any performance investigation. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#8-ftdc-full-time-diagnostic-capture]
Samples every second: full serverStatus, replSetGetStatus, oplog metadata, system CPU/memory, WiredTiger internal stats. Samples every 200ms: lighter CPU/I/O subset for sub-second spike reconstruction. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#8-ftdc-full-time-diagnostic-capture]
Location: <dbPath>/diagnostic.data/ - files rotate at ~10 MB. Atlas retains FTDC automatically; for self-managed, copy the entire directory while mongod is live (safe - FTDC uses its own write path). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#8-ftdc-full-time-diagnostic-capture]

FTDC diagnostic questions

Checkpoint stall? → WiredTiger checkpoint duration spike [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#ftdc-diagnostic-questions]
CPU saturated? → system CPU counters at 100% [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#ftdc-diagnostic-questions]
Connection spike before incident? → connections.current time series [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#ftdc-diagnostic-questions]
Replication lag gradual or sudden? → replSetGetStatus.members[].optimeDate delta [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#ftdc-diagnostic-questions]
Cache eviction pressure? → cache dirty % over time [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#ftdc-diagnostic-questions]

mongostat

Key columns: insert/query/update/delete (ops/sec), dirty (WT dirty cache %), used (WT cache %), qrw/arw (queue/active read-write), conn, repl. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#mongostat]
When to use: quick snapshot of server load; real-time cache utilization; spotting queue buildup. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#mongostat]

mongotop

Shows per-collection total/read/write ms per interval. When to use: identify hottest collection during a performance issue. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#mongotop]

db.currentOp()

When to use: real-time slow op investigation; finding lock waiters (waitingForLock: true). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#dbcurrentop]

Atlas Profiler and Performance Advisor

Cluster → Profiler tab: near-real-time slow queries (~2 min pipeline latency) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#atlas-profiler-and-performance-advisor]
Cluster → Performance Advisor: automatic index recommendations ranked by avg execution time × frequency [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#atlas-profiler-and-performance-advisor]
Default slow threshold: 100ms (configurable to 0ms) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#atlas-profiler-and-performance-advisor]

system.profile

Key fields: millis, planSummary (IXSCAN vs COLLSCAN), keysExamined, docsExamined, queryHash. Caution: profiling level 2 has measurable overhead - use level 1 with tuned slowms in production. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#systemprofile]

Root causes

Secondary under-resourced (upgrade tier or distribute reads) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#root-causes]
Flow control (MongoDB 4.2+) - check replSetGetStatus.flowControl.isLagged [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#root-causes]
Chained replication - check rs.status().syncSourceHost [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#root-causes]
Long-running transactions on secondary [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#root-causes]
Network partition/bandwidth saturation [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#root-causes]

Atlas connection limits by tier

Connections are per-node. A 3-node M30 replica set has 9,000 total across all nodes. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#atlas-connection-limits-by-tier]

Tuning recommendations

Single MongoClient per process (most common leak: new client per request) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#tuning-recommendations]
Lambda/serverless: maxPoolSize=5–10, maxIdleTimeMS=60000 [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#tuning-recommendations]
Enable waitQueueTimeoutMS to surface exhaustion quickly rather than hanging [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#tuning-recommendations]

Free and shared tier clusters (M0, M2, M5)

M0, M2, and M5 clusters do not support configurable maintenance windows. Atlas manages all maintenance entirely, with no operator control over timing. These clusters may be restarted at any time. Upgrade to M10 or higher for maintenance window control. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#free-and-shared-tier-clusters-m0-m2-m5]
This is a common point of confusion - the project-level maintenance window setting applies only to dedicated-tier clusters (M10+). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#free-and-shared-tier-clusters-m0-m2-m5]

Maintenance window configuration

Atlas maintenance windows are configured at the project level and apply to all dedicated-tier (M10+) clusters within that project. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#maintenance-window-configuration]
Location: Atlas UI → Project Settings → Maintenance Window [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#maintenance-window-configuration]
Default behavior: When no custom window is configured, Atlas selects the window (commonly Tuesday 10:00–12:00 UTC for many regions). Configure an explicit window aligned with your lowest-traffic period for production workloads. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#maintenance-window-configuration]
Configuring a custom window: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#maintenance-window-configuration]
- Choose day of week (Sunday through Saturday; Sunday=1 in the API/CLI, matching the integer table below) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#maintenance-window-configuration]
- Choose start hour in UTC (0–23); the window is exactly 1 hour [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#maintenance-window-configuration]
- Changes take effect immediately and persist until cleared [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#maintenance-window-configuration]
Important scope limitation: Project-scoped, not per-cluster. To set different windows for dev vs. prod clusters, place them in separate Atlas projects. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#maintenance-window-configuration]
Atlas CLI commands: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#maintenance-window-configuration]
Day-of-week values: Sunday=1, Monday=2, Tuesday=3, Wednesday=4, Thursday=5, Friday=6, Saturday=7. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#maintenance-window-configuration]

What triggers maintenance

Emergency security patches bypass the maintenance window entirely. Atlas notifies project and organization owners via email, but the window configuration does not constrain it. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#what-triggers-maintenance]

How Atlas performs rolling maintenance

Secondaries first - one at a time, waiting for each to rejoin and catch up before proceeding. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#how-atlas-performs-rolling-maintenance]
Primary last - triggers a replica set election. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#how-atlas-performs-rolling-maintenance]
Election window - typically 10–30 seconds; writes temporarily unavailable, reads fall back to secondaries. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#how-atlas-performs-rolling-maintenance]
mongos nodes (sharded clusters only) - restarted last. Skip for replica-set-only deployments. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#how-atlas-performs-rolling-maintenance]

Application impact: Drivers with retryable writes handle the election transparently. Applications without retryable writes may see one transient write failure. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#how-atlas-performs-rolling-maintenance]

Alert during maintenance: The "Primary election" alert fires during every maintenance restart. Configure a lower-urgency channel for this alert type or correlate it with the maintenance window time. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#how-atlas-performs-rolling-maintenance]

Total duration: 3-node replica set: 5–15 min. Sharded clusters: multiply per-shard restart time by shard count (30–60 min for large topologies). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#how-atlas-performs-rolling-maintenance]

Deferring maintenance

Deferral postpones by exactly 7 days, once only per scheduled event [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#deferring-maintenance]
After one deferral, maintenance executes at the rescheduled time - no further deferral [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#deferring-maintenance]
Critical security patches cannot be deferred - attempting to defer returns an error [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#deferring-maintenance]

Querying the maintenance window via API

Response fields: dayOfWeek (1–7, absent if no custom window), hourOfDay (0–23 UTC), startASAP (maintenance queued for next opportunity), autoDeferOnceEnabled. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#querying-the-maintenance-window-via-api]

Emergency and critical security patches

Same-day or next-day notice for critical CVEs; 24–48 hours for lower-severity updates [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#emergency-and-critical-security-patches]
Notifications sent to all Project Owners and Organization Owners [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#emergency-and-critical-security-patches]
Cannot be deferred; rolling restart procedure still used to minimize impact [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#emergency-and-critical-security-patches]
Monitor Activity Feed (Atlas UI → Project → Activity) for maintenance start/completion timestamps [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#emergency-and-critical-security-patches]

Minimizing application impact

Why serverSelectionTimeoutMS=30000 matters: With 3000ms, a 12-second election causes ServerSelectionTimeoutError before the new primary is elected. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#minimizing-application-impact]
Post-election warm-up: First queries to the new primary may be slower (30–60s) while connections re-establish and the WiredTiger cache warms. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#minimizing-application-impact]

Atlas maintenance for sharded clusters

Sequence: config server replica set (CSRS) → shard replica sets (sequentially) → mongos routers (parallel, stateless). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#atlas-maintenance-for-sharded-clusters]
Balancer: suspended during maintenance; in-progress migrations complete, no new ones start. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#atlas-maintenance-for-sharded-clusters]
Duration estimate: per-shard restart time × shard count + CSRS + mongos. A 4-shard cluster at 10 min/shard ≈ 40–50 min for shards alone. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#atlas-maintenance-for-sharded-clusters]

Customer communication template

Replace all [bracketed] placeholders before sending. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#customer-communication-template]
Placeholder guide: [HH:MM]–[HH:MM] UTC = configured 1-hour window (e.g., "02:00–03:00 UTC"). Always include: specific UTC time window, < 30s impact (not full restart duration), explicit no-data-loss statement, retryable writes note, escalation path. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-monitoring-observability/#customer-communication-template]

Where this helps

Setting up production alerting on a new Atlas cluster and needing sane threshold defaults (CPU, replication lag, oplog window, connection count) instead of guessing. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Diagnosing a performance incident after the fact using FTDC data, when the profiler wasn't capturing the right window or the issue was too transient to catch live. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Choosing between Atlas's built-in dashboards, a third-party integration (Datadog, New Relic, Prometheus), and lower-level tools (mongostat, mongotop, FTDC) for a specific monitoring need. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Planning around an Atlas maintenance window so a rolling restart doesn't surprise the application, especially for clusters without retryable writes configured. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Project ideas

Build an alert-tuning audit that checks a project's configured thresholds against documented baselines (CPU 75-85%, replication lag 10-15s for OLTP, oplog window never below 4 hours) and flags gaps. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Build a connection-pool leak detector that watches waitQueueSize and connection-creation rate to catch the "new MongoClient per request" antipattern before it exhausts the tier's connection limit. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Prototype an FTDC-based incident reconstructor that pulls the diagnostic.data directory and answers standard triage questions (checkpoint stalls, CPU saturation, replication lag onset) automatically. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Wire New Relic APM trace correlation to MongoDB slow operations so a slow application transaction can be traced directly to the database operation that caused it. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Antipatterns

Opening a new MongoClient per request instead of one per process — the single most common connection-pool leak, and the first thing to check when a cluster hits its connection limit. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Assuming the project-level Atlas maintenance window applies to M0/M2/M5 shared-tier clusters, when those tiers have no operator control over maintenance timing at all. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Running the profiler at level 2 in production, incurring measurable overhead, instead of level 1 with a tuned slowms threshold. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Setting serverSelectionTimeoutMS too low for an environment where elections can take 10-30 seconds, causing ServerSelectionTimeoutError before a new primary is even elected. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Known issues

Free and shared-tier clusters (M0, M2, M5) provide reduced metric granularity (5-minute resolution vs. 1-minute for dedicated tiers) and can be restarted at any time with no maintenance-window control. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Atlas maintenance windows are project-scoped, not per-cluster — running dev and prod clusters in the same project means they share one maintenance window, so separating them requires separate Atlas projects. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Emergency and critical security patches bypass the configured maintenance window entirely and cannot be deferred, so a carefully scheduled low-traffic window offers no protection against an urgent CVE patch. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
FTDC captures serverStatus-level metrics every second but does not capture query shapes or slow queries, so it cannot substitute for the profiler when the question is which query was slow. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Children

Atlas Maintenance Windows
Atlas Metrics and Dashboards (frontier)
Atlas Alerts (frontier)
Datadog Integration (frontier)
Prometheus Integration (frontier)
New Relic Integration (frontier)
FTDC Diagnostics
Slow Query Monitoring (frontier)
Replication Lag Monitoring (frontier)
Connection Metrics (frontier)

Frontier under this node: Atlas Alerts, Atlas Metrics and Dashboards, Connection Metrics, Datadog Integration, New Relic Integration, Prometheus Integration, Replication Lag Monitoring, Slow Query Monitoring

← the whole tree · 3D view· how to read this page