At a glance
Instance Uptime is how long the mongod process has been running continuously since it last started, for the selected period. It is the simplest health proof point in the Executive Overview: a long, steady uptime means the process has not crashed or been restarted, while a sudden reset to near zero means the member has just come back from a restart, a crash, or a failover, which is worth knowing about even when everything now looks healthy.
What it tracks
The card reports the Instance Uptime for the selected period: the number of seconds (rendered as days, hours, and minutes) that thismongod has been up since its last start. The value comes straight from the uptime field of the serverStatus command, which the server resets to zero every time the process starts. Read it as a stability signal rather than an availability percentage: an uptime that climbs steadily day after day confirms the member is stable, whereas an uptime that has unexpectedly reset points at a restart you may not have planned. On a replica set, compare uptimes across members; if one member’s uptime is much lower than its peers it has restarted recently, which often correlates with an election (see Elections (24h)) or a member that dropped out and rejoined. Note that uptime measures the process, not data availability: a replica set can serve traffic throughout a single member’s restart because another member takes over as primary.
Reconciling against the source
To check natively, rundb.serverStatus().uptime in mongosh for the raw seconds, or db.hostInfo() and the mongod log start-up lines to confirm when the process last began. On MongoDB Atlas, the cluster’s process restart history and the Metrics tab show the same restarts as uptime resets. Compare uptime per member across the replica set to spot a node that has restarted out of step with its peers.