Microsoft Sentinel Data Connector Not Ingesting Logs: Root-Cause Checklist
Reach 50,000+ security professionals
Sponsor a newsletter slot and put your brand in front of CISOs, engineers, and IT decision-makers.
The pattern is familiar to anyone who has run a SOC on Microsoft Sentinel for more than a few months: an analytic rule that used to fire regularly against a given data source goes quiet, or a dashboard that tracks ingestion volume shows a flat line where a source used to show steady traffic. Nothing in the Sentinel portal necessarily throws an alert about it, because a connector that has stopped sending data does not always announce itself as an error state; it can just sit there, disconnected in substance if not in the status label, while the SOC assumes coverage that no longer exists.
The fix depends entirely on correctly identifying which of a small number of causes is actually responsible, and guessing wrong wastes the exact time that matters most when a detection blind spot is open. This guide works through that diagnosis in order: what actually causes a previously working connector to stop, how to check ingestion health without guessing, how to fix each cause, how to confirm the fix actually worked, what to do when it does not stick, and when the problem is bigger than one team can resolve alone.
Causes: what actually stops a working connector from ingesting
A connector that stops ingesting is a symptom with a short list of underlying causes, and most incidents map cleanly onto one of them. The order below reflects how often each one shows up in practice, not a fixed sequence you have to check in order.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Diagnostics: confirming ingestion health instead of guessing
Sentinel gives you several places to check ingestion health, and checking them in a deliberate order, from the workspace level down to the specific connector, avoids wasting time investigating the wrong layer.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Fixes: resolving each cause once it's confirmed
Each cause above has a specific, mostly mechanical fix. Applying a fix that doesn't match the confirmed cause, such as rotating a credential when the real problem is a daily cap, wastes the time a live detection gap can't afford.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Validation: confirming ingestion actually resumed
A connector showing 'Connected' again, or a credential that has been successfully rotated, is not the same as confirmed ingestion. Validate against actual record counts before closing out the incident.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Failure cases: when the fix doesn't stick
Some fixes hold immediately. Others resolve the symptom for a few hours before the same gap reappears, usually because the underlying cause wasn't actually what was fixed.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Escalation criteria: your team versus Microsoft Support
Most connector failures resolve with the steps above, owned entirely by the team running Sentinel. A smaller set of situations are worth a Microsoft support case rather than continued self-diagnosis.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
The bottom line
A Microsoft Sentinel data connector that stops ingesting logs almost always traces to one of a short list of causes: an expired credential, a Data Collection Rule or Data Collection Endpoint problem, a workspace that silently hit its daily cap, a Conditional Access policy blocking the service account, a source-side format change, or permissions drift on a managed identity. Diagnose in order, from the connector's own status and 'Last Log Received' timestamp, to SentinelHealth for a 'Data fetch status change,' to Heartbeat for agent-based sources, to _LogOperation for daily cap events, before touching any configuration. Fix the specific cause rather than the nearest available setting, then validate with an actual record-count query against the affected table rather than trusting a status label that says 'Connected.' Watch for a fix that doesn't stick, most often a daily cap that keeps getting hit because the real driver was never identified, and escalate to Microsoft Support when the health tables themselves show no actionable detail, when a Microsoft-managed connector breaks immediately after a Microsoft-side update, or when the gap has already produced a confirmed detection miss that needs both a connector fix and a coverage review. A connector deployed correctly in the first place, using the practices in the Microsoft Sentinel deployment guide and validated with the query patterns in how to write KQL queries for Microsoft Sentinel, still needs this kind of ongoing health checking, because none of the causes above are one-time deployment mistakes; they're all things that can happen to a connector that worked correctly for months before something changed underneath it. Teams using Security Copilot to investigate Sentinel gaps should also confirm workspace SCU allocation is adequate -- throttling in one workspace does not draw from another even in the same tenant, and the Security Copilot SCU throttling troubleshooting guide covers the diagnostic and remediation steps.
Frequently asked questions
Why did my Microsoft Sentinel data connector suddenly stop ingesting logs?
The most common reasons are an expired API credential or service principal secret, a Data Collection Rule that was changed or that targets the wrong workspace or region, a Log Analytics workspace that hit its daily ingestion cap and silently stopped accepting new data, or the source system changing its own log format or API in a way the connector no longer parses. Less common but real causes include Azure AD Conditional Access blocking the connector's service account after a policy change, and permissions drift on a managed identity that used to have the access it needed and no longer does. Checking SentinelHealth, Heartbeat, and _LogOperation in that order narrows down which of these it is before you touch any configuration.
What is the SentinelHealth table and how do I use it to diagnose a connector problem?
SentinelHealth is a Log Analytics table that Microsoft Sentinel writes success, failure, and partial success events into for supported data connectors, once the health feature has been turned on for the workspace. Querying it for the 'Data fetch status change' operation surfaces the most recent failure events per connector and any drift from a success state to a failure state, which is usually faster than manually checking each connector's status tile in the Sentinel portal one at a time. The table is only populated for connectors that support health monitoring, and only from the point health monitoring was enabled forward, so it will not retroactively explain a gap that predates turning the feature on.
Why does the Heartbeat table matter if my connector isn't agent-based?
The Heartbeat table specifically covers agent-based sources, meaning machines reporting through the Azure Monitor Agent or a Log Analytics agent rather than API-based or Data Collection Rule-only connectors. If the affected source is one of those machine-based sources, an absence of recent Heartbeat rows for that computer means the agent has stopped communicating entirely, which points at the host, its network path, or the agent service itself rather than at anything inside Sentinel's parsing or rule configuration. For pure API-based connectors like Office 365 or Azure AD, Heartbeat will not have relevant rows and SentinelHealth or the connector's own status page in the portal is the more useful signal.
How do I tell if a Log Analytics workspace daily cap is the reason ingestion stopped?
Query the _LogOperation table for 'Data collection stopped' and 'Data collection resumed' operation events, since these are written specifically when a workspace's daily ingestion cap has been reached and when collection has resumed after the workspace's reset hour. Data collection resumes automatically once the reset hour passes, so a cap-related stoppage will look like an ingestion gap for a bounded, roughly daily-length window rather than an indefinite stoppage, which is a useful pattern for distinguishing a cap hit from a genuinely broken connector that will not fix itself without intervention.
My Data Collection Rule looks correctly configured. What else could be wrong?
A Data Collection Rule that looks correct in the portal can still fail silently if it targets a Log Analytics workspace in a different Azure region than the DCR itself, a mismatch that Azure does not flag as an error in the configuration UI. It is also worth checking whether the Data Collection Endpoint (DCE) associated with the DCR is reachable from the source and whether the DCR's data flow transformation, if one is configured, is silently dropping or malforming records rather than rejecting them outright. A DCR that was edited as part of an unrelated change, such as a table schema update after a connector version upgrade, is another common way a previously working configuration stops working without anyone intentionally breaking it.
How long should I wait before concluding a newly reconnected connector is actually broken?
Microsoft's own troubleshooting guidance for several connector types cites roughly 20 to 30 minutes as the typical delay between a connector being connected or reconfigured and data actually becoming visible in the workspace, so treat that as the minimum wait before escalating a fresh reconnection as a failure. Beyond that window with no data and no corresponding SentinelHealth or Heartbeat entries, move on to checking credentials, the Data Collection Rule, and the daily cap rather than continuing to wait, since a genuine failure will not resolve itself just by waiting longer.
Sources & references
- Microsoft Learn - Monitor the health of your Microsoft Sentinel data connectors
- Microsoft Learn - Troubleshoot why data is no longer being collected in Azure Monitor
- Microsoft Learn - Set a daily cap on a Log Analytics workspace
- Microsoft Learn - Troubleshoot CEF and Syslog via AMA connectors in Microsoft Sentinel
- Microsoft Learn - Troubleshoot Azure Storage Blob connector issues
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Daily briefings + Google Top Stories in one step.
Enter your email and we'll subscribe you to the daily briefing and add Decryption Digest to your Google Search feed at the same time.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.