Azure DocumentDB metrics are intermittent after an outage yesterday

Intermittent null values in Azure Monitor after the outage usually mean the metric pipeline expected data but did not receive a measurement for those intervals. In Azure Monitor, NULL is different from 0, and line charts can show those gaps as dashed or dotted segments.

For Azure DocumentDB, the supported facts point to two likely areas to check:

1. Metric collection/display gap after the incident
   If the cluster is otherwise healthy but only some metrics are intermittent, this can be a monitoring data gap rather than ongoing database failure. A similar Microsoft Q&A case for another Azure database service documented a portal metrics visibility issue caused by a code defect in the metrics/log collection component.
2. Resource pressure around the outage
   Reaching around 80% memory is a meaningful signal. Azure DocumentDB guidance recommends watching memory closely, and for read-heavy workloads, using cluster tiers with more RAM. If CPU or memory pressure was sustained before the outage, scaling the cluster tier is the documented action to improve performance.

Practical next steps:

1. In Azure portal > Azure DocumentDB resource > Metrics, keep the same metric but change the time granularity and aggregation window. Azure DocumentDB metrics are aggregated at 5-minute intervals by default, and changing granularity can help confirm whether this is a charting/aggregation artifact.
2. Check CPU percent, Memory percent, Committed memory percent, Storage percent, and IOPS together for the same time range. The goal is to see whether only memory has gaps or whether multiple platform metrics are missing.
3. If memory usage is still trending high, scale up the cluster tier. This is the documented action when utilization pressure affects performance; for read-heavy workloads, more RAM is specifically recommended.
4. Set alerts for capacity pressure. Microsoft recommends disk alerts and CPU monitoring, and the metrics article also recommends closer monitoring once storage utilization rises above 80%. Applying the same operational approach to memory pressure is reasonable for early warning.
5. If the cluster is functioning normally but the memory metric continues to show intermittent null values after the outage, open a support request. That pattern is consistent with a metrics collection/display issue rather than a user-fixable database setting.

Cause summary:

• Most likely cause: missing metric samples after the outage, shown as NULL by Azure Monitor.
• Possible contributing cause: the cluster was under memory pressure before the incident.
• Fix path: verify whether the gap is only in metrics, review related resource metrics, and scale the tier if pressure remains; if only the metric is affected, support intervention is the appropriate next step.

• Explore Azure Monitor in Azure DocumentDB
• Explore Azure Monitor in Azure DocumentDB
• Frequently asked questions about Azure DocumentDB (with MongoDB compatibility)
• Azure Monitor Metrics aggregation and display explained
• Use the Azure portal to set up alerts on metrics for Azure DocumentDB
• Postgres flex DB suddenly stopped reporting some metrics (but not all) - Microsoft Q&A