Azure support

Several actions can help improve response and resolution when Azure technical support feels slow or unprofessional:

1. Set the correct severity and describe impact clearly
   • Ensure each case’s severity accurately reflects business impact. Severity A should be reserved for issues that completely block users or services and have no workaround; this helps avoid de-prioritization of truly critical issues.
   • Use a meaningful title and description that capture what, who, how, and when (for example: “App Service deployment fails on region X after upgrade to runtime Y with error Z”).
   • Provide clear repro steps and “IS / IS NOT” context (what scenarios are affected vs. not affected). Poor descriptions and missing repro steps are a major cause of slow root cause determination.
2. Provide complete problem details and data when opening the ticket
   • When creating the support request in the Azure portal, fill out the Problem details section thoroughly, including:
     • When the problem started
     • Exact error messages
     • Steps to reproduce
   • Upload a log file or compressed archive (for example, browser trace or service logs) so engineers have the data needed from the start.
   • In Advanced diagnostic information, consider selecting Yes to allow collection of advanced diagnostic data from resources; this can significantly speed investigation.
3. Use the Azure portal flow correctly to avoid delays
   • Create the case from Help + Support in the Azure portal and make sure to complete all steps through Review + create so the case is actually submitted.
   • If the portal suggests automated solutions during creation, always return to the support request and click Next until the request is finalized.
4. Align expectations with support plan and response targets
   • Response time and maximum severity available depend on the support plan and region. Verify the current plan and whether it supports the severity levels being used.
   • For critical incidents, ensure Severity A is used only when appropriate; overuse can cause congestion and slower handling overall.
5. Escalate or open a new case when appropriate
   • If an issue is part of a broader Azure service disruption, first check Azure Service Health. If the incident is listed there, updates will be posted centrally and opening multiple tickets is unnecessary.
   • If experiencing issues not covered by an active Service Health incident, or if help is needed with recovery steps, open a support case and clearly state:
     • Affected resources
     • Subscription ID
     • Region
     • Business impact
   • During or shortly after a service disruption, a free support ticket can be raised for up to 72 hours after mitigation to assist with recovery.
6. When delays persist, consider support plan review
   • If frequent critical issues require faster response and deeper engagement, review whether the current support plan level is sufficient. Higher-tier plans provide higher maximum severity and faster response targets.
7. For non-technical or operations issues
   • For billing, activation, or operational issues (for example, overage invoices, adjustments, enrollment transfers), use the recommended paths such as Azure help + support or the Volume Licensing Central My Cases and Support workspace to reach the correct team directly, which can reduce back-and-forth and delays.

Applying these practices—especially precise severity, high-quality problem descriptions with data, and correct use of the Azure portal support workflow—typically leads to faster triage, fewer handoffs, and more predictable resolution timelines.

References:

• Advanced search tips for finding Microsoft troubleshooting content
• Create an Azure support request
• What to do during an Azure service disruption
• How to engage with Microsoft Operations
• Microsoft Professional Support (pay-per-incident): FAQ