How to Troubleshoot Azure General Issues (2026 Guide)
Why Azure Troubleshooting Is Harder Than It Looks
Here's the scenario I see every week: you're trying to spin up a new virtual machine, deploy a resource group, or expand into a new Azure region , and something just stops working. No clear error. No obvious fix. The portal gives you a vague message, and Azure's own search results return hundreds of articles that don't quite match your situation.
I've worked through this with teams ranging from solo developers to enterprise architects managing thousands of subscriptions. The frustration is real. Azure is one of the most powerful cloud platforms on the planet, but when things go wrong, the error messages rarely tell you the whole story. A quota error looks like a permissions error. A region access restriction looks like a service outage. An Access Control (IAM) bug looks like your directory is broken.
The root causes behind most general Azure issues fall into a handful of buckets. First, quota and subscription limits , Azure enforces per-region, per-subscription caps on compute cores, storage accounts, and SQL instances. You can hit these silently during a deployment and get back an error that doesn't actually say "quota exceeded" in plain English. Second, regional service availability, not every Azure feature is lit up in every region. Products like Microsoft Purview Information Protection, Insider Risk Management, and Communication Compliance have hard dependencies on specific Azure geographies. If your tenant's primary country/region doesn't have those dependencies available yet, the feature simply won't work, no matter how many times you click the button. Third, access-restricted regions, some Azure regions require you to formally request access through a support ticket before your subscription can provision anything there. Trying to deploy to one of these without the right approval will fail at the ARM layer with a permissions-style error that's easy to misread.
And then there's the search problem. Microsoft publishes thousands of KB articles, learn docs, and community posts. Finding the right one for your exact Azure issue, especially under pressure during an incident, is its own skill. Knowing where to look and how to phrase your search makes a significant difference.
If you're seeing failures in the Azure portal, hitting walls with region deployment, or can't figure out why a feature isn't available for your tenant, you're in exactly the right place. Let's work through this systematically. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you go deep on Azure troubleshooting, run through this fast checklist. I've seen these three things account for roughly 60% of the "why isn't Azure working" questions I get.
Check your subscription's region access. Go to the Azure portal, open Help + support from the left navigation pane, and look at any recent support requests. If you've been trying to deploy to a restricted region, like certain government or data-residency regions, there's a good chance your subscription hasn't been approved for access yet. This is a documented process, not a bug. The portal won't always scream "REGION RESTRICTED" at you. It'll just fail.
Verify your tenant's primary country/region for feature dependencies. Some of the most-used compliance and security features in Microsoft 365 and Azure have geographic dependencies. As of October 2024, Azure feature dependencies are available in countries like Australia, Canada, the UK, the US, Germany, India, Japan, and about fifteen others. If your tenant is registered outside those regions, certain features won't be available, period. Taiwan and New Zealand are listed as coming online, so check the Microsoft Message Center for the latest timeline if you're in those regions.
Try Microsoft's own search first, but search smarter. Don't search "Azure not working." Search for the exact error code you're seeing, combined with the resource type. For example: Azure VM deployment error QuotaExceeded eastus2. Microsoft's troubleshooting content is indexed well, but the broad queries return noise.
If none of those apply, keep reading, the step-by-step section covers the most common Azure troubleshooting scenarios in detail.
These two problems look almost identical on the surface but have completely different fixes. Getting this diagnosis right saves hours.
In the Azure portal, navigate to Subscriptions in the top search bar, select your subscription, then go to Usage + quotas in the left blade. This page shows your current consumption vs. your approved limits for compute cores (vCPUs), storage accounts, public IP addresses, and other resource types, broken down by region. If you're near 100% on any of these, that's your problem.
For region access issues, the diagnostic is different. Try navigating to Virtual Machines > Create and in the Region dropdown, look for the region where your deployment is failing. If the region doesn't appear in the list at all, your subscription doesn't have access to it. If it appears but deployment fails with an error containing the string AuthorizationFailed or a quota-related message at the ARM level, you likely need to request access formally.
Common quota-related error codes to watch for:
OperationNotAllowed
QuotaExceeded
RequestDisallowedByPolicy
SkuNotAvailable
If you see SkuNotAvailable, that's often a sign that the VM series you're requesting isn't available in that region at all, not just a quota cap. You'll need to either switch VM series or switch regions. Once you've confirmed which issue you're facing, move to Step 2 or Step 3 accordingly.
Quota increases for standard Azure regions go through a well-defined path. This isn't a long process, most requests for common VM series in mainstream regions resolve in one to three business days.
Start in the Azure portal. Click Help + support in the left-side navigation pane (the question mark icon near the bottom). Then click Create a new support request.
On the new support request form, fill in these fields exactly:
- Issue Type: Service and subscription limit (quotas)
- Subscription: Select the specific subscription you need the quota increase on
- Quota type: Compute-VM (core-vCPUs) subscription limit increases
Click Next, then in Problem details, click Enter details. Here you'll select your deployment model (use ARM unless you have a legacy reason for Classic), pick the region you need the increase for, choose the VM series (for example, Dv3, Esv5, or whatever you're deploying), and enter your new requested vCPU limit.
Be realistic but give yourself headroom. If you need 50 cores now, request 100. Changing quotas repeatedly is more friction than requesting once with buffer. After saving those details, set a severity level appropriate to your urgency, Severity C for non-urgent, B if a project is blocked, A only for production outages. Fill in your contact method and submit.
You'll get a ticket number. Keep it. The Azure Engineering team validates the request and may ask follow-up questions, so respond promptly if you get an email from them.
This step is for when the region you need isn't just quota-limited, it's access-restricted. Certain Azure regions, particularly those tied to specific national data residency requirements or government use, require your subscription to be formally approved before you can deploy anything there. Trying to deploy without that approval will fail at the ARM layer.
To check which regions are access-restricted, Microsoft documents these in the Azure paired regions reference page. Once you've confirmed the region is restricted, here's how to request access.
In the Azure portal, go to Help + support > Create a new support request. Fill in:
- Issue Type: Service and subscription limit (quotas)
- Subscription: The subscription you want to enable, and if you need multiple subscriptions enabled, list the additional Subscription IDs in the description field rather than filing separate tickets
- Quota type: Other Requests
In the Description field, write something like: "Request access for the Azure [region name] region for [your organization name]." Then include your intended deployment model (ARM), and your estimated quota for compute (cores), storage (TB), and SQL (SKU type and number of databases). If you're not sure what you'll need, start with these baseline figures:
Deployment Model: ARM
Planned Compute: 25 cores
Planned Storage: 10 TB
Planned SQL SKU: S0
Planned Databases: up to 20
Once your request is approved, the region becomes visible in your portal and behaves like any standard Azure region. You'll also automatically gain access to associated services like App Services and Azure Functions within that region.
This is one of the most confusing Azure troubleshooting scenarios because the feature appears in your admin center, you have the right license, and there's no error, the feature just silently doesn't work or shows as unavailable.
The cause is often that your tenant's primary country/region doesn't yet have the underlying Azure infrastructure dependency for that feature. This affects a specific set of products, including:
- Insider Risk Management
- Microsoft Threat Protection (MTP)
- Microsoft Purview Information Protection
- Autolabeling for sensitivity labels
- Communication Compliance
- Attack Simulation
- Microsoft Application Protection and Governance (MAPG)
- Privacy and Transport features
As of October 2024, these Azure dependencies are active for tenants in Australia, Brazil, Canada, France, Germany, India, Israel, Italy, Japan, Norway, Poland, Qatar, Singapore, South Africa, South Korea, Sweden, Switzerland, UAE, the UK, and the USA. Taiwan and New Zealand are scheduled to follow, check your Microsoft Message Center (accessible via the Microsoft 365 admin center under Health > Message center) for the exact enablement date for your region.
Important: this restriction applies to your tenant's primary country/region only, not to any subsidiary or satellite regions your organization operates in. If your primary tenant region isn't on the list yet, there's no workaround within the portal. Your options are to wait for the region rollout (tracked in Message Center) or raise it with your Microsoft account team.
I know this sounds basic, but a huge number of Azure issues stay unresolved longer than they should simply because engineers can't find the right documentation. Microsoft's knowledge base is enormous, and the search experience can be inconsistent. Here's how to cut through the noise.
Always start with the exact error code or message string. Copy it verbatim from the portal, the Azure Activity Log, or your deployment output. Then search for it paired with the resource type. For example:
site:learn.microsoft.com "QuotaExceeded" "Dv3" Azure VM
The Azure Activity Log is your best friend here. Go to Monitor > Activity log in the portal, filter by your subscription and time range, and look for operations with "Failed" status. Click into any failed operation, the JSON detail pane shows the exact ARM error code and a message body that's far more specific than what appears in the portal UI.
For file exchange with Microsoft Support (for example, sharing diagnostic logs or receiving a script from a support engineer), Microsoft uses a Secure File Exchange system, your support engineer will share a link directly in your open support ticket. Never accept file transfer requests through personal email or chat; always go through the official support ticket portal.
If you're searching the Azure docs directly, filter to the last 12 months where possible. Azure services update frequently, and articles older than a year sometimes describe UI flows or configuration options that have since changed. When you find a useful article, note the "Last updated" date before following the steps.
Advanced Troubleshooting for Azure General Issues
Once you've exhausted the standard portal-based fixes, these deeper techniques help resolve the cases that don't fit the common patterns.
Azure Activity Log and Diagnostic Settings
The Activity Log is your first stop for any deployment or configuration failure. Navigate to Monitor > Activity log, set a time range that covers your incident window, and filter by Status: Failed. Each entry contains a full JSON error payload under the "JSON" tab in the detail pane. The code and message fields in that JSON are often more specific than anything the portal surface shows you. Copy those values into your troubleshooting search.
For persistent or intermittent issues, enable Diagnostic Settings on the affected resource. Go to your resource, find Diagnostic settings in the left blade, and route logs to a Log Analytics workspace. From there, you can run KQL queries like:
AzureActivity
| where ActivityStatusValue == "Failure"
| where TimeGenerated > ago(24h)
| project TimeGenerated, OperationNameValue, Properties
| order by TimeGenerated desc
Access Control (IAM) Troubleshooting
One documented but often-overlooked issue: when adding permissions in the Azure portal under Access Control (IAM), you may find that users or groups aren't showing up in the search results, even though you know the account exists. This is a known behavior that can occur when the directory is large or when the account was recently created. Try searching by the user's full email address rather than display name, and give directory sync up to 15 minutes to catch up if the account is newly provisioned.
Reserved Instance Region Enablement
If you're planning to purchase Azure Reserved VM Instances in a region that required an access request, that region needs to be explicitly enabled for Reserved Instances as well. This is a separate approval step. In your region access request (or as a standalone ticket), include the following in the description:
Issue Type: Reserved Instance Region enablement
Subscription ID: [your subscription ID]
Region: [Azure region name]
VM Series: [e.g., Dv2, Esv5]
Planned usage in Cores: [estimated core count]
Don't make the Reserved Instance purchase until you get confirmation that this is enabled, the purchase may go through but not apply correctly.
Domains Used by Microsoft Support
In enterprise environments with strict outbound firewall rules, support tooling can fail if Microsoft's support agent domains are blocked. If a remote support session or diagnostic tool fails to connect, check with your network team to confirm that the domains used by Microsoft support agents are allowlisted. Microsoft maintains an official list of these domains, request it through your open support ticket if needed.
Escalate to a support ticket when: your quota increase request hasn't moved in more than five business days, your region access request stalled without a response, a feature that should be available for your tenant's geography simply isn't turning on, or you're getting ARM-level errors that don't match any documented error code. Microsoft Support, open a ticket directly from the Azure portal under Help + support > Create a new support request for the fastest routing to the right team.
Prevention & Best Practices for Azure Troubleshooting
Most of the Azure troubleshooting scenarios in this guide are avoidable. I don't mean that as criticism, cloud infrastructure at scale has a lot of moving parts, and nobody plans for quota ceilings until they hit one at 2am during a deployment. But once you've been through it once, there are simple habits that keep you from going through it again.
Monitor quotas proactively, not reactively. Set up Azure Monitor alerts on your subscription's vCPU usage. Go to Monitor > Alerts > Create alert rule and target the "Total Regional vCPUs" metric for each region you actively use. Set a warning threshold at 75%, that gives you a window to request increases before you're blocked. Discovering a quota ceiling mid-deployment is avoidable.
Pre-request region access for planned expansions. If your roadmap includes deploying to a new Azure region in the next quarter, submit the access request now. Even for standard regions, quota increases need lead time. For restricted regions, the Azure Engineering review adds more. A support request submitted during planning is infinitely less stressful than one submitted during a missed-deadline conversation.
Track your tenant's feature availability via Message Center. If you run Microsoft 365 compliance products, Purview, Insider Risk, Communication Compliance, subscribe to Message Center posts from inside the Microsoft 365 admin center. Feature rollouts, Azure dependency enablements for new regions, and deprecation notices all land there before they hit the broader internet. Filter by "Azure" and "compliance" tags.
Document your Subscription IDs and region access approvals centrally. Sounds obvious, but teams often have multiple subscriptions, and it's not always clear which ones have been approved for which regions. Keep a simple registry, even a spreadsheet, of: subscription ID, primary region, restricted-region approvals, quota ceiling per VM series. When you hire someone new or have an incident, this document is worth its weight in gold.
- Set Azure Monitor quota alerts at 75% utilization for each active region, catches ceiling issues before they block deployments
- File region access requests at the planning stage, not the deployment stage, add at least 5 business days of buffer in your project timeline
- Check the Microsoft Message Center weekly for Azure dependency region rollouts, especially if you run Purview or compliance workloads
- When opening any support ticket, include all affected Subscription IDs in the description field upfront, saves a follow-up exchange and speeds resolution
Frequently Asked Questions
Why can't I see certain Azure regions in the portal's region dropdown?
Certain Azure regions are access-restricted, meaning your subscription needs formal approval before they appear and become deployable. This isn't a portal bug or a permissions misconfiguration on your end, it's a deliberate gate that requires submitting a support request with Issue Type "Service and subscription limit (quotas)" and Quota type "Other Requests." Once approved by the Azure Engineering team, the region will appear in your portal just like any other. Check the Azure paired regions documentation to confirm whether your target region falls into this category.
How long does a quota increase request typically take in Azure?
For standard regions and common VM series like Dv3 or Esv5, most quota increase requests resolve within one to three business days. The request goes through an internal validation step with the Azure Engineering team, and they may reach out for more context about your intended workload, respond quickly to those emails to avoid delays. Restricted region access requests take longer, anywhere from three to ten business days, because the review process involves more validation. Set your ticket severity appropriately: Severity B if a project is actively blocked, not Severity A unless production is down.
Why is Insider Risk Management or Communication Compliance not available in my tenant?
These features have Azure infrastructure dependencies that are only active in specific countries/regions as of October 2024. If your tenant's primary country/region isn't in the list, which includes the US, UK, Germany, Australia, India, Japan, and about fifteen others, the feature won't activate regardless of your license. Taiwan and New Zealand are on the rollout roadmap. Check the Microsoft Message Center inside the Microsoft 365 admin center under Health > Message center for the most current timeline for your region's enablement.
I can't find users or groups when assigning roles in Azure Access Control (IAM), why?
This is a documented Azure portal behavior, not a permissions bug. When searching for users or groups in the Access Control (IAM) add-permission flow, the directory search can fail to surface results if you're searching by display name for a large directory or a recently created account. Try searching by the user's full email address (UPN) instead. If the account was just created or synced from on-premises Active Directory, wait up to 15 minutes for Azure AD to fully replicate the object before trying again.
Can I request region access for multiple subscriptions in a single support ticket?
Yes, and Microsoft actually prefers it this way. When filling out the description section of your region access support request, list all the additional Subscription IDs you want enabled. You don't need to file a separate ticket per subscription. This keeps the communication thread in one place and lets the Azure Engineering team process the approvals together. If you forget to include a subscription and remember later, reply to the existing open ticket rather than creating a new one.
How do I find the right Microsoft KB article when my Azure error message is vague?
The most reliable method is to pull the exact error code from the Azure Activity Log, not from the portal's surface-level error toast, which is often generic. Go to Monitor > Activity log, filter by "Failed" status, and click into the failed operation's JSON detail. Copy the code field value (for example, RequestDisallowedByPolicy or SkuNotAvailable) and search for that exact string on learn.microsoft.com combined with your resource type. Pairing the error code with the resource type and region in your search returns far more targeted results than searching the problem description in plain language.