# defaultMaxTimeMS cluster-level read timeout > Source-anchored research for defaultMaxTimeMS cluster-level read timeout. Run status: COMPLETED. Parent: [Operation rejection filters](https://llms-explorer.com/tree/operation-rejection-filters/) · 5 facets · 14 facts · page: https://llms-explorer.com/tree/defaultmaxtimems-cluster-level-read-timeout/ ## How it works - The MongoDB server implementation README says defaultMaxTimeMS takes effect only when authentication is enabled. (low confidence) (verified as of 2026-10-30) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/README_default_max_time_ms.md) - Because the implementation README assigns defaultMaxTimeMS the same semantics as maxTimeMS, interpret it as a server processing-time budget: termination occurs at designated interrupt points, client-to-server network latency is excluded, and mongos-to-mongod latency is included. (medium confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/README_default_max_time_ms.md) ## How-to and procedures - Configure a five-second default on the admin database with db.adminCommand({setClusterParameter:{defaultMaxTimeMS:{readOperations:5000}}}); inspect it with db.adminCommand({getClusterParameter:"defaultMaxTimeMS"}). (low confidence) — [source](https://www.mongodb.com/docs/manual/reference/cluster-parameters/defaultMaxTimeMS.md) ## Problems, failure modes and limitations - MongoDB 8.0 introduced defaultMaxTimeMS.readOperations as a cluster-wide fallback time limit in milliseconds for individual read operations that omit maxTimeMS. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/cluster-parameters/defaultMaxTimeMS.md) - defaultMaxTimeMS.readOperations defaults to 0, which supplies no default query timeout. It is not automatically a finite execution limit merely because the deployment uses MongoDB 8.0. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/cluster-parameters/defaultMaxTimeMS.md) ## Comparisons and alternatives - Atlas describes this timeout as a last-round mitigation that cancels overlong operations and limits resource retention; Tencent likewise identifies resource exhaustion prevention as its purpose. This is execution-time protection rather than a prediction that a query will be expensive. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/resilient-application.md) - The implementation README says users with bypassDefaultMaxTimeMS ignore the default, and root and __system have that privilege by default. Verify enforcement with the application identity rather than only an administrative identity. (low confidence) (verified as of 2026-10-30) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/README_default_max_time_ms.md) - MongoDB Atlas documents defaultMaxTimeMS as mitigation for expensive queries, including collection scans from missing indexes; database teams can set the fallback centrally rather than rely on every application to set a timeout. Mydbops independently describes the same operational use. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/resilient-application.md) ## Facts and statements - Supported reads are find, count, distinct, dbHash, and aggregate without $out or $merge. Aggregations containing either write stage do not inherit this default, although an explicit maxTimeMS can still apply. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/cluster-parameters/defaultMaxTimeMS.md) - An explicit operation-level maxTimeMS overrides the cluster default, including a longer timeout for legitimate analytics work; the setting therefore is not a mandatory upper bound on every read. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/cluster-parameters/defaultMaxTimeMS.md) - The MongoDB server implementation README says defaultMaxTimeMS has an effect only with authentication enabled. Users granted bypassDefaultMaxTimeMS ignore the default; root and __system include that privilege by default. (low confidence) (verified as of 2026-10-30) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/README_default_max_time_ms.md) - DRIVERS-3474 reports that timeoutMS=0 in a mongosh URI does not override defaultMaxTimeMS, whereas explicit maxTimeMS(0) does. Its July 22, 2026 update describes the Node.js driver's infinite client timeout as not emitting a server maxTimeMS override and leaves the spec change unresolved. (low confidence) (verified as of 2026-07-22) — [source](https://jira.mongodb.org/browse/DRIVERS-3474) - Crossplane's provider-mongodbatlas v1.6.0 API, published October 22, 2026, exposes optional DefaultMaxTimeMs with JSON name defaultMaxTimeMs and Terraform name default_max_time_ms, showing a declarative configuration surface for the setting. (low confidence) (verified as of 2026-10-22) — [source](https://pkg.go.dev/github.com/crossplane-contrib/provider-mongodbatlas/apis/namespaced/mongodbatlas/v1alpha2) - The implementation README says commands exceeding defaultMaxTimeMS return MaxTimeMSExpired. This is an execution timeout, not a guarantee that the operation is rejected before execution begins. (low confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/README_default_max_time_ms.md)