Microsoft Sentinel Data Connector Shows Disconnected But Is Sending Logs: How to Diagnose It

Microsoft's own Q&A and documentation point to a small set of realistic explanations, and they are not mutually exclusive; you can have more than one at once.

• The connector's health check evaluates a different signal than actual ingestion. For Azure Monitor Agent (AMA) based connectors, such as Common Event Format via AMA, the connected status is tied to whether the connector has an associated Data Collection Rule (DCR), not to whether events are actually arriving in the destination table. If the DCR is missing, misconfigured, or was never linked correctly, the portal reports disconnected even while logs land in the workspace, for example through a separate legacy connector still running in parallel against the same table.
• A permission or API-level change breaks the health check without breaking ingestion. A role assignment change on the Data Collection Rule, Data Collection Endpoint, or workspace, or an API change on Microsoft's side, can cause the connector page's own status query to fail or return an unhealthy result, while the underlying pipeline, the AMA extension on the source machine, the syslog daemon feeding it, keeps functioning independently of that status check.
• Normal ingestion delay is being mistaken for a connector failure. Every data type has its own ingestion delay between when an event is generated and when it is actually queryable in the workspace. If you are checking for "recent" data using a narrow time window right after setup, or during a period of high volume, you can see what looks like a gap or a stalled connector when the pipeline is simply behind by its normal margin, not broken.
• The portal's own status display is cached and slow to refresh. The connector health widget polls periodically rather than reading live state on every page load, so a real but already-resolved blip, or a DCR association you just fixed, can continue to display as disconnected for a period after the underlying problem is gone.

Do these in order. The point is to establish ground truth in the data tables first, before you trust or distrust what the portal's status badge is telling you.

1. Query the actual destination table directly. For a CEF or Syslog connector: CommonSecurityLog | where TimeGenerated > ago(1h) | summarize count() by DeviceVendor, DeviceProduct (or Syslog for the raw table). For AMA-based heartbeat or agent health signals: Heartbeat | where TimeGenerated > ago(1h) | summarize count() by Computer. If rows are coming in, ingestion is not actually stopped, whatever the portal badge says.
2. Check whether a Data Collection Rule is actually associated with the connector. In the Sentinel Data connectors page, open the connector's configuration and confirm a DCR is linked; if you are running an AMA-based connector, this is the specific check Microsoft's own support staff pointed to as the cause of a disconnected-but-sending-logs report.
3. Measure real ingestion delay instead of guessing. Use the Kusto ingestion_time() function against the table in question: TableName | extend delay = ingestion_time() - TimeGenerated | summarize avg(delay), percentile(delay, 95). Compare this against the connector's expected delay rather than assuming any lag means a broken pipeline.
4. Check the Workspace Usage Report's End-to-End Latency dashboard, built into Sentinel/Log Analytics, which shows measured latency by table across your workspace without you having to hand-write the query yourself.
5. Check for a duplicate or parallel legacy connector. If both a legacy agent-based connector and an AMA-based connector are configured against the same data type, one can be actively sending data while the other's status check independently reports disconnected, which is exactly the scenario Microsoft's Q&A thread describes.
6. Check the source-side agent extension health directly, not just the portal. On the VM sending logs: for Linux, systemctl status azuremonitoragent; in the Azure portal, the VM's Extensions blade should show the AzureMonitorAgent (or AzureMonitorLinuxAgent/AzureMonitorWindowsAgent) extension in a provisioning-succeeded, running state.

Apply whichever fix matches what your diagnostics actually found; do not apply all of these speculatively.

• If the DCR is missing or misconfigured: create and associate the correct Data Collection Rule with the connector following Microsoft's own "Connect CEF and Syslog via AMA" documentation. This is the specific fix Microsoft support gave for the disconnected-but-sending-logs report, and it directly addresses a health check that was looking at the wrong signal.
• If permissions were the break: verify and restore the role assignments the health check depends on (typically Monitoring Contributor or a DCR-specific role) on the Data Collection Rule, Data Collection Endpoint, and workspace, rather than only re-checking the connector's own settings blade.
• If it is genuine ingestion delay, not a broken connector: do not treat this as a connector outage at all. Instead, adjust the look-back period on any scheduled analytics rules reading that table, and apply the ingestion-time filter pattern Microsoft documents: TableName | where TimeGenerated >= ago(ingestion_delay + rule_look_back) | where ingestion_time() > ago(rule_look_back). This prevents both missed events (from too-short a look-back) and duplicate alerts (from an extended look-back that overlaps the previous run).
• If a legacy connector is redundant: once you have confirmed the AMA-based connector is the sole active pipeline for that data type, retire the legacy connector so its independent status check stops producing a confusing, contradictory reading going forward.
• If the portal status is simply stale: wait out one polling cycle after confirming the underlying fix (DCR association, permission restore) took effect, rather than assuming the fix failed just because the badge has not refreshed yet.

The connector page turning green is not itself proof the underlying problem is resolved; the data table is the source of truth.

• Re-run the direct table query (CommonSecurityLog, Syslog, or the relevant table) over a rolling recent window, for example the last 15 minutes, at two or three points over the following hour, to confirm continuous rather than one-off ingestion.
• Confirm the connector page itself now shows connected, and note how long it took to refresh after your fix, so you have a baseline for how much lag to expect from the status display itself next time.
• If the original trigger was a scheduled analytics rule that seemed to be missing events, check that rule's run history and any incidents around the previously affected window to confirm the gap is actually closed, not just that new data is arriving.
• Re-measure ingestion delay with the ingestion_time() query a day or two later and compare it against the Workspace Usage Report's latency dashboard, to confirm the delay has settled back into its normal range for that data type rather than continuing to grow.

Be precise about which of these you are actually looking at, since they call for different next steps.

• DCR is correctly associated and the data table confirms continuous ingestion, but the portal still shows disconnected after 24 hours. This points to a portal display or caching issue rather than a real pipeline problem; it is worth reporting to Microsoft, but it does not require further changes to your data pipeline.
• The direct table query shows genuinely no data, or a real gap, even after your fixes. This means ingestion actually did stop, and you are no longer looking at a false-disconnected scenario. Redirect your troubleshooting to the source side: AMA extension health on the sending host, network connectivity from that host to the Azure Monitor ingestion endpoints, and any firewall or private link configuration that could be blocking the path.
• Measured ingestion delay is far outside the documented norm and keeps growing rather than stabilizing. This is no longer a look-back-period tuning problem; it can indicate throttling, a quota limit, or a genuine upstream processing bottleneck, and needs to be treated as its own investigation rather than solved with a bigger look-back window.
• Two connectors both claim ownership of the same table and give contradictory status. Until you retire the redundant one, expect the status badge to remain an unreliable signal for that data type regardless of what you fix on either connector individually.

Escalate to Microsoft support when:

• You have confirmed, with a direct KQL query against the destination table, that ingestion is genuinely healthy, and you have confirmed the DCR association and permissions are correct, but the connector status in the portal still reports disconnected after more than 24 hours.
• The measured ingestion delay from the ingestion_time() query is significantly outside the range shown in the Workspace Usage Report's own latency dashboard for that table, and it is not trending back down.
• You suspect the health check logic itself, not your configuration, is at fault (for example, an AMA connector whose DCR is confirmed correctly associated but whose status still will not clear), which is closer to a product-side issue than something you can fix from your own tenant.

Have ready: the workspace ID, the exact connector name and type, the DCR and Data Collection Endpoint resource IDs, the KQL query and its results showing the destination table's actual state over the affected window, a screenshot or export from the Workspace Usage Report's End-to-End Latency dashboard, and the timestamp when the discrepancy between the portal status and the actual data first appeared.

Once you have confirmed the logs really are landing and the connector status was the misleading signal, the next question, whether the alerts firing on top of that data are worth an analyst's time or are mostly noise, is a separate detection engineering problem. How to Score, Tune, and Retire Noisy SIEM and EDR Detection Rules covers that triage process.