Azure Monitor Not Working, Diagnosed and Fixed (2026 Guide)
Why Azure Monitor Is Not Working, The Real Reasons
I've seen this exact situation play out dozens of times: you've spent an afternoon configuring Azure Monitor, you're expecting to see logs flowing into your workspace, and then, nothing. The portal shows no data. Your Diagnostic Settings appear to be saved correctly. Your agents look healthy. Yet Azure Monitor is not working, and the error messages Azure gives you are so generic they might as well say "something went wrong, good luck."
Here's the truth: Azure Monitor is not a single product, it's an umbrella over a stack of interconnected services. Activity Logs, Log Analytics workspaces, the Azure Monitor Agent (AMA), the legacy Microsoft Monitoring Agent (MMA), Application Insights, Diagnostic Settings, and connectors to Sentinel all have to talk to each other correctly. When any one of them is misconfigured, the whole pipeline goes silent. That's why "Azure Monitor not working" can mean five completely different things depending on your setup.
The most common root causes I see in enterprise environments break down like this:
- Diagnostic Settings pointing at the wrong Log Analytics workspace. You saved a setting, but it's shipping data to a workspace in a different subscription or region, one your team doesn't have access to.
- Agent registration failures on the endpoint. Whether you're running the Azure Monitor Agent or the older MMA, a broken certificate chain or missing proxy config will silently kill telemetry collection. Error code
0x80090016("Keyset does not exist") in your event viewer is a signature symptom here. - Activity Log download failures caused by volume overload. If you're trying to pull a CSV of activity logs across a wide time range, the system hits a processing ceiling and drops the request, showing a vague "file not prepared" message.
- Proxy certificates missing on machines running PowerShell or CLI commands. Your corporate proxy intercepts HTTPS traffic but the required root certificates aren't installed, so Azure CLI commands silently fail.
- Permission gaps in cross-tenant (Azure Lighthouse) configurations. If you're an MSP managing multiple tenants or exporting audit logs across tenants, a missing role assignment on the target Log Analytics workspace will block the entire flow.
- Subscription-level Activity Logs not flowing into Microsoft Sentinel because the connector settings or workspace selection was wrong at setup time.
I know this is frustrating, especially when it blocks incident response or compliance reporting that can't wait. The good news is that every one of these scenarios has a clear fix path. This guide walks you through all of them, starting with the fastest wins. Browse all Microsoft fix guides →
One thing to hold in mind before you start: changes to Diagnostic Settings and agent configurations are not instant. Microsoft's own documentation notes there's a built-in delay between when telemetry is emitted and when it arrives at its destination. Give new configurations at least 10–15 minutes before concluding something is broken.
Azure Monitor Not Working, The Quick Fix to Try First
Before you go deep into agent reinstalls or ARM template reviews, try this. Ninety percent of the time, Azure Monitor not collecting data comes down to one thing: the Diagnostic Setting is attached to the wrong Log Analytics workspace, or it was saved in a broken state. Here's how to verify and correct that in under five minutes.
Open the Azure portal and navigate to Azure Monitor in the left sidebar. From there, click Diagnostic Settings on the menu. Select the specific resource you're troubleshooting, this could be a subscription, a virtual machine, a storage account, whatever you're expecting logs from.
Click Edit Diagnostic Setting on the existing setting (or add a new one if none exists). Scroll down to the Destination details section. Under Log Analytics workspace, check two things carefully:
- Is the correct subscription selected in the dropdown? It's easy to accidentally be looking at a workspace in a different subscription.
- Is the workspace name what you expect? Not just a similarly named workspace, the exact one your team queries.
If either of those is wrong, fix it, click Save, and wait 10–15 minutes. Then run this verification query in your Log Analytics workspace to confirm data is arriving:
AzureActivity
| where SubscriptionId contains "<YourSubscriptionId>"
| order by TimeGenerated desc
| take 20If rows come back, your pipeline is healthy. If the query returns nothing after 15 minutes and your Diagnostic Setting looks correct, move on to the step-by-step fixes below, something deeper is broken.
Even when Diagnostic Settings look saved and healthy in the portal, the internal configuration can be in a broken state, particularly if the target workspace was deleted and recreated, or if a subscription move happened at some point. This is one of the most common causes of Azure Monitor activity logs not showing up anywhere.
Navigate to Azure portal > Azure Monitor > Diagnostic Settings. Identify the resource you're targeting. If you see an existing setting, don't just glance at it, click Edit Diagnostic Setting and go through every field:
- Under Category details, confirm the log categories you need are checked. If you're looking for administrative events, Administrative must be checked. If you want security events, check Security. Leaving categories unchecked means those logs simply aren't collected.
- Under Destination details, verify that Send to Log Analytics workspace is toggled on.
- Confirm the Subscription and Log Analytics workspace dropdowns both show the correct values.
After reviewing, click Save even if you didn't change anything. This forces the platform to re-validate the configuration end to end. I've personally seen broken-state settings get silently fixed just by re-saving.
There's also a known issue documented by Microsoft where a deleted Azure Event Hub gets automatically re-created by Diagnostic Settings. If you're routing logs to an Event Hub and seeing unexpected behavior, check whether a ghost Event Hub was auto-recreated, you may need to remove and reconfigure that destination.
Once you've saved, give it 10 minutes, then run the AzureActivity query mentioned in the Quick Fix section. If you're now seeing rows, you're done with this step. If not, move to Step 2.
If your Azure Monitor not working issue involves a virtual machine or on-premises server that should be sending data, the problem often lives in the agent layer. Microsoft has two generations of agents here: the newer Azure Monitor Agent (AMA) and the legacy Microsoft Monitoring Agent (MMA), also called the Log Analytics agent. Both can fail silently.
For the MMA, open Event Viewer on the affected machine (search for it in the Start menu, or run eventvwr.msc). Navigate to Applications and Services Logs > Operations Manager. Look for error events. If you see:
Error code: 0x80090016
Keyset does not existThat's a certificate/cryptography store issue. The agent's internal certificate operations are failing because Windows' key storage is corrupted or inaccessible. The fix is to clear the agent's certificate state:
- Stop the Microsoft Monitoring Agent service via
services.msc. - Navigate to
C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service Stateand delete the contents of that folder (not the folder itself). - Restart the service.
If the MMA service simply won't start at all, check the Windows Application event log for errors under source HealthService. A failed startup often points to a corrupted installation, uninstall and reinstall the agent from the Azure portal's connected machine blade.
For the Azure Monitor Agent, go to your VM in the portal, navigate to Extensions + applications, and verify AMA is listed as "Provisioning succeeded." If it shows "Failed," click on it to see the status message, then try removing and re-adding the extension. Also verify the VM has a system-assigned managed identity enabled under Identity, AMA requires this to authenticate to Azure.
After any agent fix, wait 5 minutes and then check Heartbeat in your Log Analytics workspace:
Heartbeat
| where Computer == "<YourMachineName>"
| order by TimeGenerated desc
| take 5Seeing rows means the agent is alive and communicating.
I've gotten this one reported by operations teams constantly: they go to download Azure Activity Logs as a CSV for an audit or incident review, and the download just fails with a vague "file not prepared" or "file not found" message. No stack trace. No error code. Just nothing.
The root cause is volume. When you request too wide a time range, say, 90 days across a busy subscription, the platform can't process that many log records into a single CSV before the request times out. The system drops it entirely rather than giving you a partial file.
Here's how to work around it reliably:
- In the Azure portal, navigate to Azure Monitor > Activity Log.
- Before clicking Download, narrow your time range. Start with a single day. If that works, expand to three days. Work up from there until you find the boundary.
- Clear your browser cache before retrying, outdated cached state can sometimes interfere with the download flow. Use Ctrl+Shift+Delete to clear cache in Edge or Chrome.
- If you need a large date range, break the request into weekly batches and merge the CSV files locally afterward.
- Check that the storage account configured to receive logs is accessible and not behind a network policy that blocks the export process.
For programmatic access to larger volumes, the Azure Activity Log API via PowerShell is significantly more reliable than the portal's CSV export. Use:
Get-AzActivityLog -StartTime (Get-Date).AddDays(-7) -EndTime (Get-Date) -MaxRecord 1000This lets you page through results in controlled batches without hitting the portal's processing ceiling. If this command itself fails, move to Step 4 to address proxy certificate issues that may be blocking it.
This one catches enterprise teams off guard all the time. You're on a corporate network, you run a PowerShell command against Azure, and it just hangs or fails with a TLS/SSL error. Azure Monitor PowerShell commands don't run. Azure CLI commands fail. But the portal works fine in your browser. What's going on?
Your corporate proxy is performing SSL inspection, it intercepts HTTPS traffic and re-signs it with a corporate root certificate. Your browser trusts that certificate because it was pushed via Group Policy. But PowerShell and the Azure CLI have their own certificate trust stores, and they haven't been told to trust your proxy's root cert. The result: every HTTPS call to Azure fails at the TLS handshake.
Here's the fix:
- Open Network & Internet settings in Windows and verify that proxy settings are configured correctly and pointing to your corporate proxy server and port.
- Get the corporate proxy root certificate from your network team, this is usually a
.ceror.crtfile. - Press Win+R, type
certmgr.msc, and press Enter to open the Certificate Manager. - Navigate to Trusted Root Certification Authorities > Certificates. Right-click, select All Tasks > Import, and import the proxy certificate.
- Open a new PowerShell window (not an existing one, you need a fresh session) and test:
Get-AzActivityLog -MaxRecord 5If that returns results, your proxy issue is fixed. For the Azure CLI specifically, also run these two commands to make sure you're on a current, well-configured version:
az upgrade
az configureaz upgrade updates the CLI to the latest release, which often includes fixes for certificate handling bugs. az configure lets you review and reset CLI-level configuration settings that might be pointing at stale endpoints.
If you're on a machine where you can't install certificates (locked-down endpoint), talk to your network team about adding Azure Monitor endpoints to the proxy bypass list: *.monitor.azure.com, *.ods.opinsights.azure.com, and *.oms.opinsights.azure.com.
If you've set up Sentinel and connected Azure Monitor to it but Azure Monitor activity logs are not showing in Sentinel, or they were showing and then stopped, the most likely culprit is a misconfigured or stale Diagnostic Setting pointing at the wrong workspace. Sentinel depends on Log Analytics under the hood, so the workspace selection has to be exact.
Here's the configuration path to verify:
- Open the Azure portal and navigate to Azure Monitor > Diagnostic Settings.
- Select the subscription (not an individual resource, you want subscription-level Activity Logs).
- Click Edit Diagnostic Setting on the existing setting.
- Under Destination details, make sure Send to Log Analytics workspace is enabled and the workspace shown is the same workspace that Microsoft Sentinel is connected to. This is the most common mistake, Sentinel is on Workspace A, but Activity Logs are being shipped to Workspace B.
- Save the setting.
- After 10–15 minutes, run this validation query directly in your Sentinel-connected Log Analytics workspace:
AzureActivity
| where SubscriptionId contains "<YourSubscriptionId>"
| order by TimeGenerated desc
| take 10If data appears in this query, Sentinel will be able to see it. Also navigate to Microsoft Sentinel > Data connectors, find the Azure Activity connector, and click Open connector page. There's a Validate connector settings button at the bottom, run it. It checks the pipeline end to end and surfaces specific error messages if something is misconfigured.
One final check: make sure the connector isn't configured through the older "Legacy" method (direct subscription connection) when your workspace expects the newer Diagnostic Settings method. Microsoft migrated this connector architecture and mixed-mode configurations cause data gaps.
Advanced Troubleshooting for Azure Monitor Not Working
Cross-Tenant Log Export Issues with Azure Lighthouse
If you're an MSP or you manage multiple Azure tenants and you're trying to export audit logs from one tenant to another using Azure Lighthouse, permissions errors will stop the flow cold. The error typically surfaces as an access denied message when trying to configure Diagnostic Settings on the guest tenant's resources.
The root cause is almost always a role assignment gap. The user or service principal performing the configuration needs the right role on the target Log Analytics workspace, not just on the source resource. Go to the Azure portal, navigate to the target workspace, open Access Control (IAM), and verify the account performing the configuration has either Log Analytics Contributor or Owner on that workspace.
If the user is a guest account in the resource tenant, there's an additional complication: the guest invitation linkage between their home tenant and the resource tenant can become stale over time. Microsoft documents a "Reset Guest Invitation Status" process specifically for this scenario, resetting it re-establishes the trust relationship and clears the permission error.
For organizations using ARM templates to deploy Lighthouse configurations at scale, review your template's RoleDefinitionId values carefully. A wrong GUID here means the deployed authorization won't have the correct permissions, even though the ARM deployment itself succeeds. Cross-reference against Microsoft's published role definition IDs for Log Analytics Contributor (92aaf0da-9dab-42b6-94a3-d43ce8d16293) to make sure the template is assigning exactly what's needed.
Migrating from MMA to Azure Monitor Agent, Common Migration Blockers
If you're in the middle of migrating from the legacy Log Analytics agent to the Azure Monitor Agent and your data collection broke mid-migration, you've hit one of the most common Azure Monitor not collecting data scenarios in 2025–2026. The migration has six distinct phases, and breaking any one of them drops you back to zero.
The most common places migration goes wrong: Step 3 (configuring Data Collection Rules, DCRs) is skipped or the DCRs don't match the data sources the old MMA was collecting. Always validate your DCR configuration in Step 4 before you decommission MMA at scale in Step 5. Run parallel collection from both agents for at least 48 hours, compare the data in Log Analytics, and only cut over when the AMA rows match the MMA rows in count and schema.
Application Insights Availability Tests Not Triggering
If your Application Insights ping tests aren't working, showing "failed" results or not running at all, check two things. First, verify that the URLs being tested are publicly reachable and don't require authentication. Azure's availability test infrastructure hits those URLs from external probe points, so any IP allowlisting or auth wall will cause failures that look like real outages. Second, review the test configuration for timeout settings, an overly tight timeout on a slow endpoint generates false failures that obscure whether Azure Monitor is actually broken or your endpoint just needs tuning.
Prevention & Best Practices to Keep Azure Monitor Running Reliably
After fixing Azure Monitor not working problems enough times, you start to see the same mistakes setting up shop again and again. Most of them are avoidable with a bit of upfront discipline. Here's what I recommend putting in place before you're under pressure during an incident.
Document your workspace topology explicitly. Know which Log Analytics workspace receives data from which subscriptions and resources. Write it down, a simple spreadsheet or wiki page. "The workspace in the East US 2 resource group MonitoringRG receives Activity Logs from subscriptions A, B, and C" is the kind of artifact that saves 45 minutes of portal spelunking when something breaks at midnight.
Run the verification query as a saved alert. Set up a scheduled query rule in Azure Monitor that fires if the count of AzureActivity rows drops to zero for two consecutive hours. An absent-data alert is more valuable than a metric threshold alert here, because silence is the failure mode, not a spike.
Test your agent pipeline after every OS patch cycle. Windows updates and certificate store changes can silently break MMA or AMA connections. Build a post-patch checklist that includes running the Heartbeat query. Five minutes of checking saves hours of incident response.
Keep the Azure CLI updated. Run az upgrade as part of your standard tooling maintenance. CLI versions more than six months old can have certificate handling and authentication bugs that cause intermittent Azure Monitor CLI commands not running correctly, especially behind corporate proxies.
Avoid wide time-range Activity Log exports. If you regularly need activity log exports for compliance, build an automated pipeline that exports in weekly batches to a storage account using Diagnostic Settings, don't rely on manual portal downloads for anything beyond a quick spot-check.
- Set a 15-minute reminder whenever you create or edit a Diagnostic Setting, check the verification query after that window, not immediately
- Enable system-assigned managed identity on every VM before installing the Azure Monitor Agent to prevent authentication failures at install time
- Add Azure Monitor endpoint domains to your corporate proxy bypass list to prevent TLS certificate interception from blocking agent telemetry
- Create a separate resource group for your Log Analytics workspaces and apply a resource lock to prevent accidental deletion, a deleted workspace breaks every connected Diagnostic Setting silently
Frequently Asked Questions
Why does my Azure Activity Log CSV download fail with a "file not prepared" error?
This error almost always means you've requested too many log records at once. The Azure portal's CSV export has a processing limit, and when the number of activity log entries in your selected time range exceeds it, the system drops the entire request and shows you a vague failure message rather than a partial file. The fix is straightforward: narrow your time range to a single day first, confirm that downloads work, then work up from there. For large-volume exports, anything over a week, use the PowerShell cmdlet Get-AzActivityLog with a -MaxRecord parameter instead, which lets you page through results in controlled batches without hitting the portal ceiling.
How do I avoid Azure activity log download failures in the future?
The most reliable way is to stop relying on manual CSV exports entirely for anything compliance-grade. Configure a Diagnostic Setting to continuously ship Activity Logs to a storage account or Log Analytics workspace, that way the data is always there, already organized, and you can query or export exactly what you need without hitting volume limits. If you do need one-off exports, break them into weekly batches and download each one separately, then merge the files. Clearing your browser cache before each download also helps, since stale cached state can sometimes interfere with the download request.
My Azure Monitor Agent looks healthy in the portal but no data is appearing in Log Analytics, why?
A healthy extension status in the portal only means the agent binary is installed and running, it doesn't mean your Data Collection Rules (DCRs) are correctly configured and associated with the VM. Check that at least one DCR is associated with the machine under Azure Monitor > Data Collection Rules, and that the DCR specifies the correct data sources (Performance, Syslog, Windows Event Log, etc.) and targets the right Log Analytics workspace. If the DCR exists but data still isn't flowing, verify the VM has a system-assigned managed identity enabled, AMA uses that identity to authenticate its data upload, and without it, telemetry is silently dropped.
I'm getting error 0x80090016 "Keyset does not exist" in my event logs, what does that mean?
That error code means Windows' cryptographic key storage, which the Microsoft Monitoring Agent uses internally for certificate operations, is in a corrupted or inaccessible state. It's a known issue that can appear after Windows system updates or profile migrations. The fix is to stop the MMA service (services.msc), delete the contents of the Health Service State folder at C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\, then restart the service. This forces the agent to rebuild its internal state from scratch. After restarting, check Event Viewer for a few minutes, if the error stops appearing and you see successful connection events instead, you're good.
Azure Monitor PowerShell commands aren't running on our corporate network, how do I fix that?
The culprit in a corporate environment is almost always SSL inspection by the proxy: your proxy re-signs HTTPS traffic with a corporate root certificate that PowerShell doesn't trust by default. Get the corporate root certificate file from your network team (usually a .cer file), open Certificate Manager by running certmgr.msc, and import it into the Trusted Root Certification Authorities store. Open a fresh PowerShell window after importing and test with Get-AzActivityLog -MaxRecord 5. Also run az upgrade and az configure if you're using the Azure CLI, outdated CLI versions have known certificate-handling issues that a simple upgrade resolves.
My subscription Activity Logs were flowing into Sentinel fine, and then they just stopped, where do I start?
Start by confirming the Diagnostic Setting still exists and points to the correct Log Analytics workspace, the one Sentinel is actually connected to. It sounds obvious, but I've seen workspace migrations and subscription reorganizations quietly orphan Diagnostic Settings so they point at a deleted or wrong workspace. Go to Azure Monitor > Diagnostic Settings, select your subscription, click Edit on the existing setting, and verify the workspace under Destination details. Then go to Microsoft Sentinel > Data connectors > Azure Activity and hit the "Validate connector settings" button, it runs an end-to-end check and will tell you specifically where the pipeline is broken. If both look correct, run the AzureActivity query in Log Analytics to see whether data is there but Sentinel's connector is the gap, or whether no data is arriving at all.