Azure Portal service status
Open the provider’s incident information and match its component, region and update time to your problem. A status-page headline does not test your individual account.
Live Domain Check
Run a live reachability check for portal.azure.com. Compare the regional responses with the problem you see in Azure Portal.
Find Azure Portal help and reporting links, specific checks, and step-by-step guidance below the live result.
Checking reachability from multiple regions.
The Azure portal can fail to render or sign in while deployed workloads remain available.
The checker above requests portal.azure.com from eight configured locations and shows the responses and measurement times. Compare those observations with the actual Azure Portal action that failed. A homepage response alone cannot verify an account, app workflow or transaction.
Open the provider’s incident information and match its component, region and update time to your problem. A status-page headline does not test your individual account.
Use Service Health and Resource Health for account/resource detail when accessible.
Compare the website entrypoint with your browser or app. This website link is separate from a provider incident dashboard.
Use Service Health and Resource Health for account/resource detail when accessible.
Open Azure Portal help / reporting. Use the contact, technical-help or account route described there. Sign-in, support entitlement and available channels can vary; a public community discussion is not a private support ticket.
Portal blade URL, tenant/subscription, browser error, correlation ID and UTC time.
Attach the checker’s downloaded JSON if it helps show the hostname, regional responses and original timestamps. Describe what happened in your browser or app as well. A report sent to WebsiteDown.org is not automatically forwarded to Azure Portal.
These are troubleshooting comparisons, not claims that Azure Portal is currently experiencing a particular incident.
Compare an existing workload's endpoint with the failing portal blade and record whether the shell or one resource view fails.
Consult Azure Status/Service Health; ask an authorised colleague to check the same subscription before changing access roles.
A 403 or 429 means the host answered but refused or limited that request. A timeout gives no HTTP response. Keep those outcomes separate and check the available-region count before treating the result as broad evidence.
Use these local troubleshooting steps after the down-check workflow when Azure Portal seems broken only for you. This section focuses on app, browser, account, and network fixes.
Open portal.azure.com in your current browser, then test in a private window or second browser. If only one session fails, compare its account, cookie and extension context before assuming the entire service is unavailable.
Keep an existing working session and preserve unsaved work. For a sign-in failure, use the official account-help route. Avoid repeated password or security resets until you confirm this is not a broader Azure Portal issue.
Compare Wi-Fi and mobile data only where you are permitted to do so. Keep required VPN, proxy and security controls in place, and record which network fails.
Save timestamp, device, network type, exact error, final URL, and status code. Use the check workflow above before contacting Azure Portal support.
Run the portal.azure.com check and compare its original timestamps and responses with your actual error. The Azure portal can fail to render or sign in while deployed workloads remain available.
Use the official help/reporting resource linked above. Use Service Health and Resource Health for account/resource detail when accessible.
Compare an existing workload's endpoint with the failing portal blade and record whether the shell or one resource view fails. Consult Azure Status/Service Health; ask an authorised colleague to check the same subscription before changing access roles.
Portal blade URL, tenant/subscription, browser error, correlation ID and UTC time.