MongoDB Write Concern Timeout Exceeded – Fix It Fast

You're running a write operation (like an insert or update) on your primary MongoDB node. You set w: majority or w: 2 to make sure the write is safe. Then the app hangs. After a few seconds you get this error: WriteConcernTimeout. It means the primary waited for confirmation from the secondary nodes, but they didn't reply in time.

This usually happens during peak hours—like when your e-commerce site is processing orders fast. The secondaries are overwhelmed with replication traffic. Or maybe their disk is slow (spinning HDD instead of SSD). Or the network between your nodes has high latency (like 10ms+). The primary gives up waiting.

What causes the timeout?

The root cause is simple: your write concern expects confirmation from N nodes, but at least one of those nodes didn't apply the write before the wtimeout clock ran out. The default wtimeout is 0 (no timeout), but many drivers set it to 5000ms or so. If you don't set wtimeout, MongoDB won't timeout—but your app will block forever if a secondary is down. So that's not better.

Here are the real triggers I've seen in production:

• One secondary has a high CPU from a bad index or slow query.
• Network packet loss between nodes—just 1% loss can delay replication.
• Disk write latency on a secondary > 100ms (common with cloud EBS volumes under load).
• The primary itself is under memory pressure and drops replication connections.

How to fix it – step by step

1. Check which node is slow. Run rs.status() on your primary. Look at the optimeDate for each member. If one secondary has a much smaller date (like minutes behind), that's your problem node.
2. Check disk I/O on that slow secondary. SSH into it and run iostat -x 1 (Linux) or vmstat 1. Look at the %iowait or await column. If it's over 50ms, your disk can't keep up. Fix: upgrade to SSD, move your MongoDB data to a faster drive, or reduce write load.
3. Increase the wtimeout value. In your driver, set wtimeout: 10000 (10 seconds) instead of the default. This gives the slow node more time. But don't go over 30 seconds—that just hides the problem.
4. Lower the write concern. If you don't really need w: majority (like for logs or analytics), drop it to w: 1. That means only the primary confirms. Risk: you lose that write if the primary crashes before replication. But your app won't timeout.
5. Check network latency between nodes. Run ping from primary to each secondary. If you see > 5ms, that's adding up. Use tcpdump to look for retransmissions. If you find packet loss, talk to your network team.

What if it still fails?

If you did all the steps above and still see the timeout, look at these:

• Check for a long-running operation on a secondary. Run db.currentOp() on the secondary. You might see a slow index build or a mapReduce job blocking replication.
• Verify your MongoDB version. Versions 4.0 and older had bugs with write concern under heavy load. Upgrade to 5.0 or 6.0 if you can.
• Check if you have a hidden secondary. Hidden members still count toward w: majority. If that hidden node is on a slow drive, it'll cause timeouts. Either remove it from the replica set or give it better hardware.
• The last resort: use a custom write concern. Instead of majority, set w: 2 (you plus one secondary). That's faster than majority but still gives you one backup. Only do this if you understand the risk.

Most times, the fix is step 1 or 2. Find the slow node, fix its disk or network, and the timeout goes away. Don't just increase the timeout blindly—that's like turning up the radio to ignore engine noise.