How to fix MongoOperationTimeoutError: Operation timed out in MongoDB

Extend the driver’s timeout windows so it can wait longer for a primary, especially in multi-region or heavy-traffic clusters:

const client = new MongoClient(uri, {
  serverSelectionTimeoutMS: 60000, // wait up to 60s for a healthy node
  socketTimeoutMS: 45000,          // wait 45s for a response once connected
  connectTimeoutMS: 30000,
  waitQueueTimeoutMS: 20000,
});

The MongoDB docs recommend tuning these [connection options](https://www.mongodb.com/docs/drivers/node/current/connect/connection-options/#std-label-node-connection-options) based on your expected latency. Driver defaults are safe for local clusters, but distributed deployments often need the extra headroom.

Apply maxTimeMS to operations that scan large collections so the server kills them before the driver’s deadline. Also ensure indexes cover the query and limit the result set:

const cursor = collection.find({ status: 'active' });
cursor.maxTimeMS(10000); // let MongoDB abort after 10 seconds
await cursor.toArray();

Add indexes on the filters and projections you use, and paginate rather than requesting the entire dataset. maxTimeMS appears in the [how to limit server execution time guide](https://www.mongodb.com/docs/drivers/node/current/fundamentals/connection/#how-to-limit-server-execution-time) and protects both the client and the server from runaway operations.

Use the shell and monitoring tools to ensure replica set members are reachable, not lagging, and have the resources to finish operations:

mongosh --quiet <<'EOF'
printjson(rs.status());
printjson(db.serverStatus().connections);
printjson(db.currentOp({secs_running: {$gt: 10}}));
EOF

Watch mongostat or Atlas metrics for high latency, CPU spikes, or election storms. If the driver cannot find a PRIMARY before serverSelectionTimeoutMS, it will return the same timeout error even if the network is fine.

Load balancers, proxy servers, and corporate firewalls often kill idle connections in 30–60 seconds. Match those values to your driver settings and enable TCP keepalive:

proxy_connect_timeout 60s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;

On AWS ALB/ELB, bump the Idle Timeout to 120s or more. Azure and GCP have similar settings. Ensure keepAlive packets actually flow (the Node driver enables keepalive by default). Without this, the driver may time out even though the server would eventually respond.

Wrap operations in retries when they are idempotent. The driver already supports retryReads and retryWrites, but application-level retries let you handle non-idempotent work safely:

const result = await retry(async () => {
  return await collection.updateOne({ _id }, { $inc: { counter: 1 } });
}, {
  retries: 3,
  minTimeout: 1000,
  maxTimeout: 10000,
});

Use a library like p-retry (npm) and log the retry attempts. If retries still get timeouts, a deeper bottleneck or timeout configuration must be addressed before adding more attempts.