SLA for MongoDB Atlas

MongoDB will use commercially reasonable efforts to maximize the availability of its MongoDB Atlas Service, and provides performance guarantees as detailed below. This Service Level Agreement (“SLA”) applies only to MongoDB Atlas deployments at level M30 or above that have been up for a minimum of 24 hours. The SLA does not apply to any other product offered by MongoDB. Capitalized terms have the meaning set forth in the Cloud Terms of Service unless otherwise set forth below.

If we do not achieve and maintain the SLA as set forth on this page, then you may be eligible for a credit towards a portion of your monthly service fees. We may modify the terms of this SLA on 90 days notice.

SLA

Monthly Uptime Percentage Service Credit
< 99.995% but equal to or greater than 99.0% 10%
< 99.0% 25%

Definitions

"Applicable Monthly Service Fees" means the total fees actually paid by you for MongoDB Atlas that are applied to the month in which Downtime occurred.

"Downtime" is the total accumulated minutes during a calendar month for a given MongoDB Atlas cluster during which the entire MongoDB Atlas cluster is unavailable. A minute is considered unavailable for a given MongoDB Atlas cluster if all continuous attempts by Customer to establish a connection to the MongoDB Atlas cluster within the minute fail. Downtime does not include scheduled downtime for maintenance or upgrades. Partial minutes of unavailability will not be counted towards Downtime.

"Monthly Uptime Percentage" for a given MongoDB Atlas cluster is calculated as the total number of minutes during a given billing month less Downtime divided by the total number of minutes during that billing month. If you have been running your MongoDB Atlas cluster for only part of the month, your MongoDB Atlas cluster is assumed to be 100% available for the portion of the month that it was not running.

"Service Credit" is the percentage of the Applicable Monthly Service Fees credited to you following MongoDB’s claim approval.

Terms

Claims

In order for MongoDB to consider a claim, you must log a support ticket with MongoDB within 24 hours of first becoming aware of an event that has impacted service availability. We must receive any claim for a Service Credit by the end of the calendar month following the month in which the Downtime occurred. For example, if the Downtime occurred on February 15th, we must receive the claim and all required information by March 31st.

The claim must include all information necessary for MongoDB to validate the claim, including but not limited to: (i) a detailed description of the events resulting in Downtime, including your request logs that document the errors and corroborate your claimed outage (any confidential or sensitive information in these logs should be removed or replaced with asterisks); (ii) information regarding the time and duration of the Downtime; (iii) the number and location(s) of affected users (if applicable); and (iv) descriptions of your attempts to resolve the events resulting in Downtime at the time of occurrence. You must reasonably assist MongoDB with any problem diagnosis and resolution.

We will evaluate all information reasonably available to us and make a good faith determination in our sole discretion of whether a Service Credit is owed. We will use commercially reasonable efforts to process claims during the subsequent month and within forty five (45) days of receipt. You must be in compliance with the Cloud Terms of Service in order to be eligible for a Service Credit. If we determine that we owe you a Service Credit, the Service Credit will be a credit against a future invoice for MongoDB Atlas. Service Credits will not entitle you to any refund or other payment from MongoDB.

Service Credits

Service Credits are your sole and exclusive remedy for any performance or availability issues for MongoDB Atlas under the Cloud Terms of Service and this SLA.

Service Credits apply only to fees paid for a MongoDB Atlas cluster for which the SLA has not been met.

Limitations

This SLA does not apply to any performance or availability issues:

  1. That result from any voluntary actions or inactions from you or any third party (e.g., rebooting a database instance, scaling compute capacity, not scaling storage when the storage is full, misconfiguring security groups, VPC configurations or credential settings, disabling encryption keys or making the encryption keys inaccessible, attempting to connect from an IP address that has not been confirmed and processed in the whitelist of approved IP addresses, attempting to connect when the number of connections is already at the connection limit, etc.);
  2. Due to factors outside our reasonable control (for example, natural disaster, war, acts of terrorism, riots, government action, or a network or device failure, including at your site or between your site and our Services);
  3. That result from the use of services, hardware, or software provided by a third party, including issues resulting from inadequate bandwidth or related to third-party software or services, such as cloud platform services on which MongoDB Atlas runs;
  4. Caused by your use of a Service after we advised you to modify your use of the Service, if you did not modify your use as advised; During or with respect to preview, pre-release, beta or trial versions of a Service, feature or software (as determined by us);
  5. That result from your unauthorized action or lack of action when required, or from your employees, agents, contractors, or vendors, or anyone gaining access to our network by means of your passwords or equipment, or otherwise resulting from your failure to follow appropriate security practices;
  6. That result from your failure to adhere to any required configurations, use supported platforms, follow any policies for acceptable use, or your use of the Service in a manner inconsistent with the features and functionality of the Service (for example, attempts to perform operations that are not supported) or inconsistent with our published guidance;
  7. That result from faulty input, instructions, or arguments (for example, requests to access files that do not exist); or
  8. That result from your attempts to perform operations that exceed prescribed quotas or that resulted from our throttling of suspected abusive behavior.