I think the current timeout of 30 seconds is problematic for two reasons:

1. It is in general really long. I think in almost all cases a timeout of about 20 seconds would not fail any more frequently than a timeout of 30 seconds.
2. It happens to match timeouts of some other software, such as Heroku routing layer. When software upstream of the application aborts a request there is frequently a loss of diagnostics; the driver can avoid such situations by reducing the timeout to be under 30 seconds.

Some possible values for the timeout could be:

• 15 seconds: the minimum value I think we could go with. Exceeds the default heartbeat interval of 10 seconds. Should be enough for a cold start of a replica set or sharded cluster with no data (I don't know how long it takes for a server to start with a large data set).
• 18 seconds: slightly more conservative but still speedy. Not as dramatic of a decrease from the current 30 second default.
• 20 seconds: moderate value intended to cover longer server initialization periods.
• 22 seconds: Over two heartbeat intervals, I think this is the largest value that is still sensible.

Note that this just changes the default - applications can still specify their desired timeout values.