How to fix WriteConcernError: waiting for replication timed out in MongoDB

Use rs.status(), rs.printSecondaryReplicationInfo(), and db.serverStatus() to confirm all members are SECONDARY/PRIMARY. Look at optimeDate comparisons and ensure secondaries are not stuck in RECOVERING or down.

If a node is lagging or not reachable, fix replication synchronization by repairing the oplog, restarting the member, or adding capacity so it can apply oplog entries faster.

If legitimate writes take longer than the default 1,000 ms, extend wtimeoutMS on the driver or in mongos/command.

Node.js example:

const client = new MongoClient(uri, {
  writeConcern: { w: 'majority', wtimeoutMS: 5000 },
});

For a single command:

db.collection.insertOne(doc, { writeConcern: { w: 2, wtimeout: 5000 } });

Increasing wtimeoutMS gives the replica set more time to meet the requested acknowledgment count without immediately raising an error.

If you cannot keep additional nodes healthy, consider using w:1 or w:majority with fewer tags. Changing to w:1 removes the need to wait for remote nodes entirely, though durability drops to only the primary.

Atlas tip: review the cluster tier’s replica set size, tags, and priority settings before relaxing w.

Heavy queries, index builds, or disk saturation can delay Oplog application. Keep secondaries performant by:
- Building indexes during low traffic windows
- Monitoring CPU/disk I/O spikes with Atlas/Cloud Manager
- Ensuring the oplog window is large enough
- Increasing priority or adding hidden members if you need more acknowledgement targets

Also verify network devices (firewalls, VPNs) are not closing idle connections faster than your heartbeat and wtimeout.

After fixing the root cause, either retry the failed operation (drivers support retryable writes when the server returns a writeConcernError) or switch to idempotent writes so your app can surface the retry logic without duplicating data.