Microsoft Sentinel Data Connector Not Ingesting: Troubleshooting Guide
Reach 50,000+ security professionals
Sponsor a newsletter slot and put your brand in front of CISOs, engineers, and IT decision-makers.
Microsoft Sentinel data connectors frequently show a Connected status while delivering zero events. Silent ingestion failures caused by expired service principals, misconfigured Data Collection Rules, and Azure Monitor Agent issues create detection blind spots that go unnoticed until an incident occurs. This guide walks through connector-by-connector diagnostics and verification using KQL and Azure portal tools. For building detection rules on ingested data, see the Microsoft Sentinel KQL detection rules MITRE guide.
Verifying Connector Status vs Actual Data Flow with KQL
The Sentinel connectors panel shows a green Connected status based on the last time the connector API checked in, not based on actual event ingestion. A connector can show Connected for hours or days while delivering zero logs. The definitive check is a KQL query against the workspace: union isfuzzy=true SecurityEvent, Syslog, CommonSecurityLog | summarize LastEvent = max(TimeGenerated) by Type | where LastEvent < ago(4h). If any table shows no events in 4 hours during business hours, that connector is silently failing. Cross-reference against the expected table: Microsoft 365 Defender maps to SecurityAlert and SecurityIncident; Entra ID sign-in logs map to SigninLogs; Syslog-based sources map to Syslog or CommonSecurityLog depending on the format. Run each table check separately to narrow the scope before diving into connector configuration.
Diagnosing Data Collection Rule Misconfigurations
Modern Sentinel connectors using the Azure Monitor Ingestion pipeline rely on Data Collection Rules (DCRs) to define what data to collect and where to send it. A DCR misconfiguration is a common cause of silent failure because the connector API endpoint responds successfully while the DCR itself has an invalid stream declaration or incorrect workspace association. In the Azure portal, navigate to Monitor > Data Collection Rules and filter by the subscription where your Sentinel workspace lives. Click the DCR associated with the failing connector and check the Data sources tab: the destination workspace ID must match your Sentinel workspace ID exactly. If the DCR was created in a different region than the workspace, ingestion will fail silently. Delete and recreate the DCR in the correct region. For AMA-based connectors, also check that the DCR is associated with the agent using Monitor > Data Collection Rules > the DCR > Resources.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Fixing Service Principal Authentication Expiry for API Connectors
API-based connectors (Microsoft 365 Defender, Dynamics 365, Custom Logs via API) authenticate using a service principal with a client secret or certificate. When the secret expires, the connector stops ingesting data but may continue to show Connected in the Sentinel panel for up to 24 hours while cached tokens remain valid. Check secret expiry in Azure Active Directory > App registrations > find the app used for the connector > Certificates and secrets. If the secret is expired or expires within 30 days, create a new secret and update it in the Sentinel connector configuration page. For connectors configured via Logic Apps or Azure Functions, update the secret in the function's application settings or the Logic App connection. After updating, monitor the connector for 15 to 30 minutes and run the KQL ingestion check query to confirm events are flowing.
Troubleshooting Azure Monitor Agent Health on Windows and Linux
AMA-based connectors depend on the Azure Monitor Agent being healthy on each source machine. On Windows, check the AMA service status: sc query AzureMonitorAgent. If the service is stopped, start it and check the event log under Applications and Services > Microsoft > Azure Monitor Agent > Operational for error events. On Linux, check sudo systemctl status azuremonitoragent and review /var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/ for connection errors. A common failure is the managed identity or service principal used by AMA losing access to the DCE (Data Collection Endpoint). Verify the endpoint in Monitor > Data Collection Endpoints and confirm the AMA-associated managed identity has the Monitoring Metrics Publisher role on both the DCR and the DCE. Revoke and re-grant the role if permissions were recently changed.
Resolving Syslog and CEF Forwarder Issues on Linux Machines
CEF and Syslog connectors route events through a Linux forwarder VM that receives network traffic on UDP 514 or TCP 514 and forwards it to the Log Analytics workspace using the AMA or the legacy MMA agent. If the forwarder is healthy but Sentinel shows no events, check the rsyslog or syslog-ng configuration: cat /etc/rsyslog.d/security-config-omsagent.conf and verify the workspace ID and primary key are current. For AMA-based CEF connectors, the forwarder must have the CEF-specific DCR associated via the Azure portal. Test that the forwarder is receiving traffic by running tcpdump -i any port 514 on the Linux machine while sending a test CEF event from a source device. If tcpdump shows no packets, the network path or firewall is blocking traffic. If tcpdump shows packets but Sentinel shows no events, the parsing or forwarding configuration is broken.
Monitoring Ingestion Lag vs Actual Connector Failure
Ingestion lag is distinct from connector failure. Sentinel can show zero recent events due to upstream processing delays of 5 to 15 minutes for high-volume sources, or up to 30 minutes during Azure service incidents. Use the ingestion anomaly workbook (available in Sentinel > Workbooks > search Ingestion Anomaly) to distinguish lag from failure: it shows historical ingestion volume by hour and flags tables with statistically unusual low-volume periods. For a manual check, run Heartbeat | summarize LastHeartbeat = max(TimeGenerated) by Computer to verify AMA-connected machines are reporting. If Heartbeat is current but the specific security table is empty, the DCR stream definition is filtering out events before they reach the table. Review the DCR transform query under the Data sources tab; a malformed KQL transform drops all events silently.
The bottom line
Build a Sentinel watchlist or workbook that checks LastSuccessfulIngestion for each connected table daily. Any connector that has not ingested data in 4 hours during business hours should trigger an alert. Rotate service principal credentials on a 90-day calendar and document the rotation process in your SIEM runbook so connector gaps do not appear during credential expiry windows.
Frequently asked questions
How do I verify that a Microsoft Sentinel data connector is actually ingesting events and not just showing Connected status?
Run a KQL query: union isfuzzy=true SecurityEvent, Syslog, CommonSecurityLog | summarize LastEvent = max(TimeGenerated) by Type | where LastEvent < ago(4h). If any table shows no events in 4 hours during business hours, the connector is silently failing despite showing Connected. The Connected status is based on the API check-in, not event flow.
What is the most common cause of Microsoft Sentinel connectors silently stopping ingestion after initial setup?
Service principal credential expiry is the most common cause. API-based connectors authenticate using a client secret that expires. When the secret expires, the connector stops ingesting but the Connected status may persist for up to 24 hours. Check the app registration in Azure AD > Certificates and secrets and rotate expiring credentials on a 90-day schedule.
How do I diagnose a Data Collection Rule misconfiguration that causes a Sentinel connector to ingest zero events silently?
In Azure portal > Monitor > Data Collection Rules, find the DCR for the failing connector and check that the destination workspace ID matches your Sentinel workspace exactly. Verify the DCR is in the same region as the workspace. For AMA-based connectors, confirm the DCR is associated with the agent under the Resources tab. A region mismatch causes silent failure with no error shown in the portal.
Why is the Azure Monitor Agent not forwarding events to Sentinel even though the service shows as running and healthy?
The AMA's managed identity may have lost the Monitoring Metrics Publisher role on the Data Collection Rule or Data Collection Endpoint. Revoke and re-grant the role in Azure portal > the DCR or DCE > Access control (IAM). Also check the AMA operational event log on Windows (Applications and Services > Microsoft > Azure Monitor Agent > Operational) or /var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/ on Linux.
How do I test whether a Linux CEF forwarder is receiving events from source devices before they reach Microsoft Sentinel?
Run tcpdump -i any port 514 on the Linux forwarder while sending a test CEF event from a source device. If tcpdump shows no packets, the network or firewall is blocking traffic on UDP/TCP 514. If tcpdump shows packets but Sentinel shows no events, check the rsyslog or syslog-ng configuration and verify the workspace ID and key in /etc/rsyslog.d/security-config-omsagent.conf.
How do I distinguish between Microsoft Sentinel ingestion lag and an actual connector failure when logs stop appearing?
Use the Ingestion Anomaly workbook in Sentinel > Workbooks to compare current ingestion volume against historical baselines. Run Heartbeat | summarize LastHeartbeat = max(TimeGenerated) by Computer to check AMA connectivity. If Heartbeat is current but the security table is empty, the DCR transform query is likely filtering out events. Review the transform under the DCR Data sources tab.
Sources & references
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.