// guide
Atlas rarely goes down. It degrades — slowly, on one node, in ways your application reports as its own fault. What to watch, and what Atlas already tells you.
9 min · you have an Atlas cluster · updated 23 August 2026
Managed databases have made the total outage rare. What replaced it is worse to diagnose: a cluster that is up, answering queries, passing every health check, and quietly taking eight times longer than it did last week.
Your application does not report that as a database problem. It reports it as a timeout, a 502 from a gateway, or nothing at all — a request that eventually succeeded and a user who had already left.
Connection exhaustion. The single most common Atlas incident on small products, and the one most often misdiagnosed. Every serverless invocation that opens its own client eats a connection from a fixed pool. Traffic doubles, the pool runs out, and new connections are refused while existing ones work perfectly. Half your requests fail; the cluster is fine. If you are on Workers, Lambda or Vercel functions, this is your most likely first Atlas incident, and it looks exactly like an application bug.
Replica lag. A write goes to the primary and a read a moment later goes to a secondary that has not caught up. The user creates something and it is not there. No error is raised anywhere — this is a correctness failure that presents as a user complaining they are “going mad”.
A slow primary. Usually a missing index on a collection that recently got big. Queries that were 4ms become 400ms, then 4s. Nothing fails; everything sags. This is the one that most often reaches production, because it is invisible in staging where the collection has forty documents.
Disk approaching full. Atlas will auto-scale storage if you let it, and bill you for it. If you have not, a full disk takes the cluster read-only, which turns every write path into an error at once.
A stale or expiring TLS certificate on your side. Not Atlas’s fault and still your outage. Drivers pinning an old CA bundle fail to connect after a rotation, all at once, with an error that reads like a network problem.
More than most managed databases, and it is worth using before adding anything.
Atlas has built-in alerts for connection counts, disk usage, replication lag, query targeting and CPU. They work, they are free on every tier including M0, and if you configure nothing else you should configure these. The Atlas dashboard’s Real-Time panel is genuinely good for seeing a slow query while it is happening.
Two limits worth knowing. Atlas alerts on the cluster, so it can tell you connections are at 480 of 500 but not that the checkout path is the thing consuming them. And its alerts arrive by email to whoever set up the project, which on a solo product is one address that also receives billing notices — a place urgent things go to be missed.
Beaam connects to Atlas read-only through the Atlas Administration API. It collects cluster state, connection counts against the tier limit, replication lag, disk utilisation and operation latency, every minute, and applies the same rules as everything else: repeated evidence before alerting, correlation across your other services, and a cooldown so a cluster cycling during a resize does not become twenty notifications.
The part that Atlas’s own alerting structurally cannot do is the correlation. When your API, your queue worker and your checkout all start failing in the same two-minute window, the useful message is not three alerts — it is one that says the database is the common factor and lists what it took down with it.
The highest-value signal on a database backing a commercial path is not a resource metric at all. It is two counters that are supposed to move together.
Purchases completed and deliveries confirmed. Orders created and orders fulfilled. Jobs enqueued and jobs finished. When those diverge, something is broken regardless of what every dashboard says, and the divergence is usually visible minutes before any resource metric leaves its normal band.
This is worth wiring up deliberately, because no monitoring tool can guess which two of your counters are supposed to agree.
A schema change that is slow rather than broken. A query that is correct and expensive. A collection that will be a problem in three months at the current growth rate. Those are capacity work, not monitoring, and no alert will do them for you.
It also will not catch a bug in your own data model. If your application writes an inconsistent pair of documents, the database will store exactly what it was asked to, healthily, forever.
Monitoring answers “is it healthy”. It does not answer “why did revenue dip on Tuesday” — that is a different question of the same data, and worth keeping in mind when choosing where your commercial records live. A cluster that holds orders, inventory and events together can answer both; one split across three stores can answer neither without a pipeline first.