MongoDB Search and Vector Search for Community Edition went GA on 30 June 2026. Self-managed deployments get the same mongot search process that us...
For further actions, you may consider blocking this person and/or reporting abuse
The two-tools-one-disk gap (df 28% vs mongot 89%) is the part that will bite everyone: mongot enforces its own math, so the alert should too - a recording rule on mongot_system_disk_space_data_path_free_bytes / total_bytes catches the drift before any index build wedges, while df on a quota-limited overlay never will. Same asymmetry in the API: NOT_STARTED is a hard error but a typo'd index name is a silent zero, so the cheap guard is asserting the index exists via $listSearchIndexes at startup - turns 'identical from the application side' into a boot-time failure. And the worst-of-all-hosts-ever aggregation is really append-only truth without decay: a statusDetail-vs-actual-members diff is a one-line drift check on it.
The recording rule on mongot_system_disk_space_data_path_free_bytes/total_bytes, yeah that's just... correct, and kind of embarrassing that I didn't say it outright. df was never gonna save anyone here, it's not even doing the same math mongot is doing, so alerting on it is basically alerting on vibes. Two tools, two different denominators, good luck.
The $listSearchIndexes boot check for the typo thing is the one I keep thinking about honestly. "Looks identical from the app side" was the whole annoying part of that finding, like, a typo and an empty collection give you the exact same nothing back, and the only hint is a WARN line buried in mongot's own logs that basically nobody's tailing at 2am. Turning that into a startup crash instead of a silent shrug is just... obviously better? Not sure why I didn't land there myself, might've been too deep in "huh that's weird" mode to go write the fix.
And the statusDetail-vs-members diff, yep, would've saved me some genuine head scratching with the dead-host thing. The fact that the aggregate status is "worst thing this index has EVER seen, including hosts that are long gone" is such a sneaky little trap, a fresh index with no baggage reports clean no problem, so you'd never suspect the pattern exists until the one day you restart mongot and the summary just straight up lies to you from then on.
Anyway good comment, you basically did the "what would you actually build" homework I skipped. Appreciate it.
The two-denominator trap is worth naming explicitly for the post: df and mongot disagree because they measure different things — df sees the filesystem, mongot sees its data path, and on XFS with speculative preallocation the gap is gigabytes. The recording rule on mongot's own metric is the only alert that means what it says. On the $listSearchIndexes boot check: it's three lines and it catches the typo class that looks identical from the app side — cheap enough that skipping it is the actual bug.
Small correction on the denominator bit, cause I don't want it to stick around in the thread wrong. There's no XFS or speculative preallocation in the post, and that's not where the gap came from. Both tools were looking at the same path. df was dividing by the quota-limited allowance, mongot was dividing by the full capacity the underlying device reports. That's how you get 28% vs 89% on one disk, a 60 point gap, way bigger than preallocation would ever explain.
Have you actually seen preallocation throw mongot's numbers off on XFS? If so I'd be curious, that'd be a separate trap on top of this one.
Agree on the boot check though. It's a few lines, and skipping it is how you end up debugging an empty result that was really a typo.
You're right and thanks for correcting it before it sticks — I reached for XFS speculative preallocation because it's a classic 'two tools disagree' story, but it wasn't in your post and the quota-vs-capacity split is the actual mechanism, and it's cleaner: both tools read the same path, just against different denominators. df tracks the quota-limited allowance, so it's the one that screams early, while mongot keeps reporting comfortable numbers against full capacity — which also explains why mongot's own metric never fires an alert there. To your question: no, I haven't seen preallocation move mongot's number; speculative preallocation inflates apparent usage at the filesystem level, so it would bias df upward, not mongot. The general lesson holds though: when two measurements of the same disk disagree by tens of points, check the denominators first — quota, cgroup limits, reserved blocks — before suspecting either tool.
“Alerting on vibes” is the reframe I’ll reuse with teams — two tools with two denominators means every rule on the wrong one is trust-debt you pay at 2am. For the statusDetail trap: once you confirm the worst-ever semantics, check whether the per-host membership view resets cleanly on restart — if the aggregate lies after a restart, the fix is alerting on the delta across restarts. One rule then catches both the stuck-pending and the ghost-host.