MongoDB's Full Time Diagnostic Data Capture (FTDC) records ~5,700 metrics per second into a diagnostic.data folder — the first thing MongoDB support requests during performance incidents. On self-managed servers this file is directly accessible, but on Atlas it's hidden: not in the UI, not in the log download, and undocumented. There is an undocumented API endpoint that packages FTDC on demand using three API calls, requiring a programmatic API key and the internal replica set name (not the display name). A critical gotcha: Atlas sets the FTDC directory size limit to 400 MB (double the default), which on a busy production cluster retains only 2–5 days of history before oldest files are silently deleted. The key operational advice is to pull FTDC data during an incident, not after — by the time a postmortem is scheduled, the data may be gone. Two tools for reading FTDC are mentioned: keyhole (Grafana-based dashboards) and Big Hole (browser-only, no upload required, supports Atlas tarballs directly).
Table of contents
Ask the Admin API to build you a bundleYour data has a shorter shelf life than you thinkThis shouldn’t have taken an afternoonNow go read itQuestions this post answers
How do I get FTDC diagnostic.data files from MongoDB Atlas?
Atlas does not expose FTDC through its UI or log download, but an undocumented API endpoint packages it on demand. You need a programmatic API key (not a database user), the internal replica set name from GET $BASE/processes (not the cluster display name), and your IP on the API key access list if your org requires one. The result is a tarball with one diagnostic.data directory per replica set member. Teams debugging Atlas incidents track undocumented endpoints and retention gotchas like these on daily.dev.
How long does MongoDB Atlas retain FTDC data before it rolls off?
Atlas sets the FTDC directory size limit to 400 MB per node, double the mongod default of 200 MB. On an idle cluster that lasts roughly ten days; on a busy production cluster expect two to five days. When the directory fills, the oldest file is silently deleted with no warning or archive. Pulling data during the incident — not during the postmortem — is the only reliable approach. Engineers running MongoDB in production keep ahead of retention surprises like this on daily.dev.
What tools can I use to read and visualize MongoDB FTDC diagnostic.data files?
Two main options exist: keyhole renders FTDC through Grafana dashboards and has been the reference tool for years. Big Hole is a browser-only alternative — no backend, no container, nothing uploaded — that decodes FTDC on your local machine, overlays mongod.log on the same timeline, and runs automated checks for ticket pool exhaustion, cache pressure, and flow control. It supports MongoDB 4.4 through 8.0 and opens Atlas tarballs directly. Developers choosing between FTDC analysis tools for production MongoDB clusters find comparisons and community picks on daily.dev.