How to claim an SLA credit from MongoDB Atlas (99.995% uptime)

MongoDB Atlas carries one of the strictest uptime commitments in mainstream SaaS — 99.995% on dedicated clusters — and one of the most generous credit ceilings: a bad enough month is worth 100% of that cluster's fee back. It also has the tightest notice requirement of any major vendor: a support ticket within 24 hours of noticing the outage, or the claim is dead before you ever file it.

The short answer

If a MongoDB Atlas M10 or larger dedicated cluster that has been running at least 24 hours falls below 99.995% monthly uptime, you're owed a service credit against a future invoice: 10% of that cluster's monthly fee when uptime lands between 99.0% and 99.995%, 25% below 99.0%, and 100% below 95.0%. Claiming it is a two-stage process — log a support ticket within 24 hours of first becoming aware of the downtime, then submit the full claim with evidence by the end of the month following the outage. MongoDB processes claims within 45 days. Free, Flex, and shared tiers carry no uptime SLA, so there's nothing to claim on them.

What 99.995% actually allows

This is the number that makes the Atlas SLA unusual. 99.995% monthly uptime leaves you roughly 2 minutes and 10 seconds of downtime in a 30-day month (43,200 minutes × 0.005%). For comparison, a 99.9% SLA — the common SaaS default — allows about 43 minutes a month. A single failover that takes four minutes to settle is already a breach of the Atlas commitment.

That cuts both ways. The strict target means breaches happen on incidents most teams would shrug off, which is exactly why Atlas credits go unclaimed: nobody files for a four-minute blip. It also means the measurement has to be precise — a rounding error of a minute changes whether you have a claim at all.

More on that arithmetic in what a 99.9% SLA actually allows.

What you're owed

Credits apply to the specific cluster that experienced the downtime — not your whole Atlas bill:

Two things stand out. There's no gentle ramp — the credit jumps straight from 10% to 25% the moment uptime drops under 99.0%. And the bottom band pays 100%, where most vendors cap at 50%; a catastrophic month on Atlas can zero out that cluster's invoice. Credits are applied to a future invoice or payment, never refunded as cash, and the SLA states they are your sole and exclusive remedy. Model your number with the MongoDB Atlas credit calculator — enter the cluster's monthly spend and the month's measured uptime and it returns the tier and the amount.

What's covered — and the exclusion that catches people

Coverage is narrower than "Atlas was down." The SLA applies only to M10 and larger dedicated clusters that have been up for at least 24 hours. Free, Flex, and shared tiers are excluded outright, as are Beta offerings.

The exclusion worth reading twice: MongoDB does not issue credits for downtime caused by third-party services or infrastructure, including the underlying cloud platform. If your Atlas cluster went dark because of an AWS or Azure regional failure, that failure may sit outside the Atlas SLA — while being squarely inside your AWS or Azure SLA. Read the incident's root cause before you decide which vendor to file against; on a shared-infrastructure outage you may be claiming from the wrong one. Credits are also excluded for factors outside MongoDB's reasonable control, misuse of credentials or equipment, and customer-side misconfiguration or improper scaling.

The evidence MongoDB expects

The Atlas SLA asks for more documentation than most — this is not a one-line ticket:

• A detailed description of the events causing the downtime
• Request logs documenting the errors and corroborating the claimed outage, with confidential data redacted
• The time and duration of the downtime
• The number and location(s) of affected users
• Descriptions of what you attempted to resolve it at the time
• The affected cluster name

Corroborate the window against the incident record on the MongoDB status page. Note that Atlas exposes no availability-percentage endpoint — uptime has to be inferred from cluster process metrics and the incident timeline, which is why the request logs matter.

How to claim a MongoDB Atlas SLA credit

1. The moment you become aware of the downtime, log a support ticket at support.mongodb.com — this must happen within 24 hours of first awareness, and it is what makes the later claim valid.
2. Capture evidence while it's fresh: request logs showing the errors, the start and end timestamps, affected users and regions, and the cluster name.
3. After the month closes, measure the cluster's uptime for that calendar month and match the shortfall to the 10% / 25% / 100% band.
4. Submit the full claim through MongoDB support with every required item — event description, redacted logs, duration, affected-user count and locations, remediation attempts, and the cluster name.
5. File by the end of the month immediately following the month the downtime occurred. MongoDB will process the claim within 45 days, and an approved credit lands on a future invoice.

Watch both deadlines

Atlas is the clearest example of a two-stage SLA, and teams lose credits at the first stage, not the second. The 24-hour notice ticket is the gate: miss it and the generous end-of-next-month filing window is irrelevant, because there's no qualifying ticket to attach the claim to. In practice that means someone has to recognise a two-minute breach as a claimable event on the same day it happens — which almost never occurs without monitoring.

The second deadline is more forgiving than most: the end of the following month, versus Atlassian's 15th-of-the-month cutoff. Use that room to assemble the evidence properly, not to delay starting.

Frequently asked questions

Does MongoDB Atlas refund you for downtime?

Not in cash. MongoDB issues a service credit against a future invoice for the affected cluster when it misses the 99.995% monthly uptime commitment — 10% of that cluster's monthly fee between 99.0% and 99.995%, 25% below 99.0%, and 100% below 95.0%. The SLA states service credits are the sole and exclusive remedy.

What is the MongoDB Atlas uptime SLA?

99.995% monthly uptime, on M10 and larger dedicated clusters that have been running at least 24 hours. That allows roughly 2 minutes and 10 seconds of downtime in a 30-day month. Free, Flex, and shared tiers have no uptime SLA.

How long do I have to claim a MongoDB Atlas SLA credit?

Two clocks. You must log a support ticket within 24 hours of first becoming aware of the downtime, then submit the complete claim by the end of the month immediately following the month in which the downtime occurred. MongoDB processes claims within 45 days of receipt.

Am I owed a credit if my Atlas cluster was down for 10 minutes?

On an M10+ dedicated cluster, yes — 10 minutes is well past the ~2 minutes 10 seconds that 99.995% allows in a 30-day month, so that month is a breach and the 10% band applies to that cluster's fee. But only if you logged the support ticket within 24 hours and the cause wasn't an excluded one, such as an underlying cloud-provider failure.

Does the Atlas SLA cover an AWS or Azure outage under my cluster?

Generally no. The Atlas SLA excludes downtime caused by third-party services and infrastructure, including the underlying cloud platform. In that case the claim belongs to the cloud provider's own SLA rather than MongoDB's — check the root cause in the incident record before filing.

Methodology & caveats

The 99.995% commitment, the 10% / 25% / 100% credit bands, the M10+ and 24-hour-uptime eligibility rules, the 24-hour notice requirement, the end-of-following-month filing window, the 45-day processing time, and the exclusions above are transcribed from MongoDB's published Atlas Database SLA into Ontracko's vendor profile. Verify the operative clause and your own order form before filing — MongoDB revises its SLAs, and enterprise agreements can differ. The downtime-allowance figures are arithmetic on a 30-day month. Live Atlas incident history is on its status page; see also which SaaS vendors actually pay SLA credits, SLA credit vs service credit, the reliability rankings, and the SLA glossary.

*A 99.995% SLA means the breaches that owe you money are too short to notice by hand. Ontracko watches the MongoDB status feed, flags the breach while the 24-hour notice window is still open, and assembles the claim. Monitor MongoDB Atlas free — 8% only on recovered credits. See MongoDB live status or open the Atlas SLA calculator.*