# Investigate Connection Monitor's indeterminate state before declaring a network outage

> Distinguish missing monitoring data from a measured connectivity failure.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260917-016-investigate-connection-monitor-s-indeterminate-state-before-declaring-a-network/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-17T16:34:44+00:00
- Modified: 2026-09-17T16:35:03+00:00
- Last reviewed by DSE: 2026-09-17
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 1 minutes

## What you need to know

Distinguish missing monitoring data from a measured connectivity failure.

## Potentially affected

Use this review when an existing test becomes indeterminate, especially around a scale-in or deallocation. Identify the exact source instance, test group, configured coverage and observation window before changing network rules.

## DSE recommendation

DSE recommends keeping a missing-data investigation separate from a confirmed failed-connectivity incident.

## Article

## Source facts

Microsoft describes an indeterminate Connection Monitor test as missing data in the Log Analytics workspace and directs operators to inspect metrics. It also documents a scale-set case: a specifically selected instance may be removed during the monitoring cycle without immediate recognition, leaving the monitor indeterminate. Microsoft recommends random instance selection within coverage levels to reduce this particular discovery problem. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/network-watcher/connection-monitor-overview).

## Applicability

Use this review when an existing test becomes indeterminate, especially around a scale-in or deallocation. Identify the exact source instance, test group, configured coverage and observation window before changing network rules.

## DSE recommendation

DSE recommends keeping a missing-data investigation separate from a confirmed failed-connectivity incident. Compare source-instance existence, monitoring coverage and workspace observations first. Where suitable, have the monitoring owner assess randomized coverage against the application’s monitoring requirements. Preserve the original selection and event timeline before adjusting the test.

## Verification

Compare the selected instance’s lifecycle with metric and log timestamps. From an approved surviving source, run a harmless connectivity check to the same destination. Record that result separately from monitor recovery. Close the investigation only after the expected sources produce fresh observations and any remaining connectivity failure has its own evidence.

## Official references

[Microsoft Learn: Connection Monitor Overview](https://learn.microsoft.com/en-us/azure/network-watcher/connection-monitor-overview).

## Primary reference

- Name: Connection Monitor Overview - Azure Network Watcher | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/network-watcher/connection-monitor-overview
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Investigate Connection Monitor's indeterminate state before declaring a network outage,” DSE Security, https://update.dsesecurity.com/updates/dse-20260917-016-investigate-connection-monitor-s-indeterminate-state-before-declaring-a-network/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.