Fix Azure App Service Pages Not Loading (2026)
Why Azure App Service Pages Are Not Loading
I've seen this exact problem dozens of times , you deploy a web app to Azure App Service, the home page loads fine, everything looks great. Then someone clicks Sales Report or Manage Products and… nothing. A blank screen. A 502. An infinite spinner. The frustrating part is Azure doesn't tell you why in plain English. It just fails silently and leaves you staring at a white page wondering what went wrong.
Here's the thing: when specific pages in an Azure-hosted web app don't load while others do, it almost always comes down to one of four root causes. Understanding which one you're dealing with is the whole battle.
Cause 1, Client-side routing not configured for Azure. If you're running a Single Page Application (React, Angular, Vue, or similar), your app handles routing in the browser via JavaScript. Azure App Service doesn't know about those client-side routes. When someone navigates directly to /sales-report or /manage-products, Azure looks for an actual file at that path on the server. It finds nothing. It throws a 404 or a blank response. The fix is a rewrite rule, and it takes about two minutes once you know what to add.
Cause 2, Database or API connection failure on specific routes. Some pages are data-heavy. Your Sales Report page probably hits a database query or an internal API endpoint that your home page doesn't. If the connection string is wrong, the database firewall is blocking the App Service's outbound IP, or a dependent API is timing out, only those pages fail. The home page stays up because it doesn't need that data.
Cause 3, Cold start and memory pressure. Azure App Service on shared or Basic tier plans can run into cold start delays and memory limits. A lightweight home page loads in under a second. A report page that joins five database tables and renders 2,000 rows can trigger a 230-second request timeout or hit the plan's memory ceiling, causing the worker process to recycle mid-request.
Cause 4, App Service regional or platform incident. The South Africa North region (southafricanorth-01.azurewebsites.net) is a newer Azure region. It occasionally experiences capacity constraints and platform-level incidents that affect specific app service plans. This is rarer, but it's worth ruling out before you spend three hours debugging your code.
Azure's error messages, things like Error 500.30, ASP.NET Core app failed to start, HTTP Error 502.3, Bad Gateway, or just a blank white screen, don't distinguish between these causes at all. That's why you need a systematic approach, not just a Google search for the error code. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before anything else, open your browser's developer tools (F12) on the failing page, go to the Network tab, and reload. Look at the HTTP status code for the main page request and any failing API calls. That single number tells you which problem you're dealing with:
- 404 → Almost certainly a client-side routing / SPA rewrite rule issue
- 500 or 502 → Server-side error, app crash, bad connection string, or dependency failure
- 503 → App Service is unavailable, cold start, plan limit, or platform incident
- No response / CORS error → API or backend not reachable from the frontend origin
If you're seeing a 404 on a client-side route, this two-minute fix resolves it for the majority of Azure-hosted SPAs. In your project root, create or edit a file called web.config with the following content:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="SPA Fallback" stopProcessing="true">
<match url=".*" />
<conditions logicalGrouping="MatchAll">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Rewrite" url="/" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>Deploy this file to the root of your web app's publish directory. If you're using React with a build step, this file goes inside the /build or /dist folder that gets uploaded to Azure. For Node/Express backends, this is less relevant, your Express router handles the fallback instead.
After deploying, restart your App Service from the Azure Portal: App Services → [your app] → Overview → Restart. Then clear your browser cache with Ctrl + Shift + Delete and try the Sales Report and Manage Products pages again.
Before you change anything, you need to know what your app is actually reporting when those pages fail. Azure has a built-in log streaming feature that most developers don't know exists, and it's your fastest path to the real error message.
Go to the Azure Portal, open your App Service (pos4-epcggvc8g7hgghd3), then navigate to Monitoring → Log stream in the left sidebar. The log stream will connect and start showing live output from your application process.
Now, in a separate browser tab, navigate to the failing page, Sales Report or Manage Products. Watch the log stream. You're looking for lines like:
Application: Unhandled exception. System.Data.SqlClient.SqlException
A network-related or instance-specific error occurred while establishing a connection to SQL Server.
Application: ERROR - Cannot read properties of undefined (reading 'map')
Application: HTTP/1.1 500 Internal Server Error at /api/sales-reportIf the log stream shows nothing when the page fails, enable application logging first: go to App Service → Monitoring → App Service logs, turn on Application logging (Filesystem), set level to Verbose, and save. Then try again.
You can also pull logs via the Kudu console. Navigate to https://[yourapp].scm.azurewebsites.net/api/logstream directly. This bypasses the portal UI and sometimes gives you cleaner output. The Kudu URL for your app would be https://pos4-epcggvc8g7hgghd3.scm.azurewebsites.net.
Once you see the actual error, you know exactly which step below to jump to. If you see a database connection error, go to Step 3. If you see a 404 on a static route, go to Step 2. This saves you from working through five fixes that don't apply to your situation.
Azure App Service pages not loading due to client-side routing is by far the most common cause I encounter. Azure's IIS-based hosting doesn't know your JavaScript router exists. When someone hits /manage-products directly, IIS looks for a folder called manage-products on disk, finds nothing, and returns a 404.
The fix depends on your app's tech stack.
For React, Vue, or Angular apps (static hosting on App Service): Add the web.config file shown in the Quick Fix section to your build output folder. Then in your App Service → Configuration → General settings, make sure the Virtual path points to the correct folder (usually /site/wwwroot).
For Node.js/Express backend: You need a catch-all route at the bottom of your Express router:
// Place this AFTER all other route definitions
app.get('*', (req, res) => {
res.sendFile(path.join(__dirname, 'build', 'index.html'));
});For ASP.NET Core apps: In your Program.cs or Startup.cs, make sure you have:
app.UseStaticFiles();
app.UseRouting();
app.MapFallbackToFile("index.html"); // Add this lineAfter deploying the change, verify it worked by opening a browser in InPrivate / Incognito mode and navigating directly to your Sales Report URL. If the page loads, the routing fix worked. If you still get a 404, double-check that the web.config file is actually present in the deployed folder using the Kudu file browser at https://[yourapp].scm.azurewebsites.net/DebugConsole.
Your Sales Report page almost certainly queries a database. If the connection string is missing, wrong, or blocked, that page crashes while your home page, which might only load static content, works perfectly. I know this is frustrating, especially when the deploy seemed to go smoothly.
In the Azure Portal, go to your App Service → Settings → Environment variables (previously called Configuration). Look for your database connection string. It might be named DATABASE_URL, DefaultConnection, SQLCONNSTR_DefaultConnection, or something similar. Make sure it's there and that it points to the correct server, database name, and credentials.
Copy the connection string value and test it from the Kudu console. Open https://[yourapp].scm.azurewebsites.net/DebugConsole, then run:
# For SQL Server connections, test TCP connectivity first
Test-NetConnection -ComputerName your-server.database.windows.net -Port 1433If the connection is blocked, you need to whitelist your App Service's outbound IP addresses in your database firewall. Find your app's outbound IPs at: App Service → Properties → Outbound IP addresses. Then go to your Azure SQL Server → Networking → Firewall rules and add each IP.
Alternatively, enable the "Allow Azure services and resources to access this server" toggle in the SQL Server firewall settings, this is the fastest fix for apps within the same Azure subscription. Once the firewall rule is saved, restart your App Service and test the failing pages again. You should see the Sales Report and Manage Products data appear within seconds of the restart completing.
Azure App Service pages not loading because of timeouts is sneaky, the page doesn't throw an error, it just hangs. Then after 230 seconds (the default Azure gateway timeout), it drops with a 502 or a blank screen. This hits data-heavy pages like sales reports hardest because they run expensive queries.
Check your App Service plan tier first. Go to App Service plan → Overview and look at your plan. If you're on Free (F1) or Shared (D1), you're limited to 60 CPU minutes per day and your app gets shut down after 20 minutes of inactivity, every page load after that is a cold start. Scale up to at least Basic B1 for any production workload.
To scale up: App Service plan → Settings → Scale up (App Service plan) → choose B1 or higher → Apply.
If you're already on a paid plan and pages still time out, check whether Always On is enabled: App Service → Configuration → General settings → Always On → On. Always On keeps your worker process warm so the first request doesn't pay the cold start penalty.
For query timeouts on your Sales Report page specifically, add a command timeout to your database calls. Here's a .NET example:
// Increase command timeout for heavy report queries
using var command = new SqlCommand(query, connection);
command.CommandTimeout = 120; // seconds, default is 30You can also add Application Insights to trace exactly where the slowdown occurs: App Service → Application Insights → Turn on Application Insights. After enabling it, reload the failing page, then check Application Insights → Investigate → Performance to see the slowest operations by duration.
If your frontend (the web UI) is separate from your backend API, which is common in POS systems where a React frontend calls a Node or .NET API, CORS errors will cause specific page loads to fail silently. The home page loads because it doesn't call the API. Manage Products fails because it immediately tries to fetch product data from an API endpoint that refuses the cross-origin request.
Open F12 → Console tab on the failing page. If you see a message like:
Access to fetch at 'https://api.yourapp.azurewebsites.net/products'
from origin 'https://pos4-epcggvc8g7hgghd3.southafricanorth-01.azurewebsites.net'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present…then CORS is your problem. Fix it in your backend API. For Node/Express:
const cors = require('cors');
app.use(cors({
origin: 'https://pos4-epcggvc8g7hgghd3.southafricanorth-01.azurewebsites.net',
methods: ['GET', 'POST', 'PUT', 'DELETE'],
credentials: true
}));For ASP.NET Core, add this to Program.cs:
builder.Services.AddCors(options => {
options.AddPolicy("AllowPOS", policy => {
policy.WithOrigins("https://pos4-epcggvc8g7hgghd3.southafricanorth-01.azurewebsites.net")
.AllowAnyMethod()
.AllowAnyHeader()
.AllowCredentials();
});
});
app.UseCors("AllowPOS");You can also configure CORS directly in Azure without changing code: App Service → API → CORS, and add your frontend's origin URL. However, the code-level approach gives you more control and works even if you deploy to a different Azure region later. After deploying the CORS fix, do a hard refresh (Ctrl + Shift + R) on the failing pages and check the Network tab, the requests should now return 200 responses instead of being blocked.
Advanced Troubleshooting
If the five steps above haven't resolved your Azure App Service pages not loading, it's time to dig into the deeper diagnostics that most guides skip. These techniques apply especially to domain-joined enterprise environments, apps using Azure Active Directory authentication, and multi-region deployments.
Event Viewer via Kudu, Reading the Application Event Log
Your app's Windows Event Log is accessible via Kudu without needing RDP. Navigate to https://[yourapp].scm.azurewebsites.net/api/dump to pull a diagnostic dump, or use the Process Explorer at https://[yourapp].scm.azurewebsites.net/ProcessExplorer to see if your worker process (w3wp.exe) is consuming abnormal memory or CPU on the failing requests.
Look for Event ID 5000 (unhandled exception), Event ID 1026 (.NET Runtime error), or Event ID 2268 (recycle triggered by memory pressure) in the Application log. These tell you if your app is crashing after receiving the request for the Sales Report page.
Azure Diagnostics, Auto-Heal and Health Check
Enable the Health Check probe: App Service → Monitoring → Health check. Set the path to a lightweight endpoint like /api/health or /ping that your app responds to. Azure will automatically restart instances that fail the health check, and it will route traffic away from unhealthy instances if you're on a Standard plan or higher.
Auto-Heal is another underused tool: App Service → Diagnose and solve problems → Auto-Heal. You can configure it to restart the process automatically when response times exceed a threshold, say, any request taking more than 60 seconds on the /sales-report path.
Azure Front Door and Regional Failover
If your app is in South Africa North and users are reporting intermittent failures, the region itself may be experiencing capacity issues. Check the Azure Status page at status.azure.com and filter for South Africa North. If there's an active incident (status icon shows yellow or red for App Service in that region), your options are to wait for Microsoft to resolve it or temporarily redirect traffic to a secondary region using Azure Front Door or Azure Traffic Manager.
Authentication and Authorization Failures
If your app uses Azure Active Directory (Entra ID) authentication and the Sales Report or Manage Products pages require a specific role claim, users without that role will hit a silent 403. Check your App Service's Authentication blade to see if "Require authentication" is enabled. Then verify the user hitting the page has the correct app role assigned in Azure Portal → Enterprise Applications → [your app] → Users and groups.
If you've worked through all five steps, checked the logs, verified connection strings and CORS, and specific pages in your Azure App Service are still not loading, it's time to open a support ticket. Specifically escalate if: your Kudu console shows the app process crashing with a memory access violation, your app is on a Premium V3 plan and still hitting timeouts, or Azure's own diagnostic tool (Diagnose and solve problems → Availability and Performance) shows platform-level issues flagged in red. Opening a ticket with a support engineer gets you access to internal platform metrics that aren't visible in the portal. Microsoft Support, use Severity B (Business Impact) for production outages to get a response within two hours.
Prevention & Best Practices
Once you've fixed the immediate issue of Azure App Service pages not loading, it's worth taking 30 minutes to set up guardrails so this doesn't happen again, especially in a production POS system where a broken Sales Report or Manage Products page directly impacts your business operations.
Use deployment slots for zero-downtime deploys. Instead of deploying directly to production, use an App Service deployment slot (Staging slot). Deploy your new build to Staging, validate that Sales Report and Manage Products work there, then swap Staging into Production. If the swap causes issues, you can swap back in about 20 seconds. This is available on Standard tier and above.
Set up Azure Application Insights alerting. Create alerts for: response time exceeding 5 seconds on any page, server-side exception rate above 1%, and availability test failures. Go to Application Insights → Alerts → New alert rule. Point the availability test at both your Sales Report endpoint and Manage Products endpoint, not just the home page. Most teams only monitor the home page and don't discover that a sub-page is broken until a user reports it days later.
Pin your Node.js or .NET runtime version. Azure periodically updates the runtime. If your app targets Node 18 and Azure quietly upgrades the platform to Node 22 in a patch window, subtle API changes can break specific features. Pin your runtime: App Service → Configuration → General settings → Stack settings → set a specific major.minor version.
Store secrets in Azure Key Vault, not in environment variables. Environment variables in App Service are visible to anyone with Contributor access to the resource. Key Vault references (@Microsoft.KeyVault(SecretUri=...)) are more secure and easier to rotate without redeployment.
- Enable Always On in App Service General Settings to eliminate cold start failures on your first daily page load
- Add a
web.configSPA rewrite rule to every frontend project before you deploy, it takes 2 minutes and prevents the most common Azure page-not-loading issue - Set up the Health Check probe pointing to a dedicated
/api/healthzendpoint that validates your database connection, not just that the process is alive - Configure Auto-Heal to restart worker processes that exceed 1.5 GB memory usage, this prevents slow memory leaks from causing your Sales Report page to hang indefinitely
Frequently Asked Questions
Why does my home page load fine but the Sales Report page shows a blank screen on Azure?
This is almost always a client-side routing problem or a page-specific data dependency failing silently. Your home page probably doesn't fetch data from a database or API on initial load, it just renders static content. The Sales Report page does, and if that API call or database query fails, the JavaScript catches the error but renders nothing. Open F12 → Network tab, reload the Sales Report page, and look for red (failed) requests in the network log. That failed request is your actual problem, not the page itself.
My Azure app was working yesterday and now specific pages don't load, what changed?
Three things commonly cause sudden failures without you changing anything: Azure platform updates (runtime version bumps that happen in maintenance windows, usually between 2–4 AM in your region's time zone), expiring SSL certificates or connection string credentials (database passwords with 90-day rotation policies), and hitting a plan quota, for example, a Free tier app that exhausted its daily CPU minutes. Check App Service → Monitoring → Metrics and look at the CPU Time metric. If it flatlined at your plan's limit, that's the culprit.
How do I see the real error message when Azure just shows a blank page with no error code?
Go to App Service → Monitoring → Log stream in the Azure Portal, then reproduce the error by clicking the failing page. The log stream will show the actual exception in real time. If that shows nothing, go to App Service → Diagnose and solve problems → Application Event Logs, this pulls the Windows Application Event Log from inside your App Service sandbox. You can also access the Kudu diagnostic console at https://[yourapp].scm.azurewebsites.net, navigate to Debug Console → CMD, and browse to D:\home\LogFiles\Application to read the log files directly.
Can I fix Azure App Service page loading issues without redeploying my code?
Yes, in several cases. If the problem is a missing environment variable or wrong connection string, you fix it in App Service → Configuration → Application settings and click Save, the app restarts automatically with the new values, no code deployment needed. If it's a firewall rule blocking your database, you add the IP in Azure SQL Server → Networking, again, no redeploy. The SPA routing fix via web.config does require deploying a file, but you can do that through the Kudu file editor at https://[yourapp].scm.azurewebsites.net/DebugConsole by editing the file directly in the browser, no CI/CD pipeline needed.
My Azure App Service is in South Africa North, is that region reliable for production apps?
South Africa North (Johannesburg) is a generally available Azure region that supports most Azure services. It's smaller than West Europe or East US in terms of available capacity, which means it can occasionally experience slower auto-scaling during peak periods. For a production POS system, I'd recommend pairing it with a deployment slot and configuring Azure Monitor alerts for availability. If you're seeing intermittent failures that don't correlate with your own deployments, always check status.azure.com first and filter for the South Africa North region before spending time debugging your application code.
How do I stop Azure from timing out on my Sales Report page that runs a heavy database query?
Azure App Service's front-end load balancer imposes a hard 230-second (about 4 minutes) request timeout that cannot be extended for standard HTTP requests, this is an Azure platform limit, not something you can change in your app config. So if your Sales Report query runs longer than that, you need to restructure the feature rather than just increasing a timeout setting. The right approach is to make the report generation asynchronous: trigger the query in the background via a queue message or Azure Function, store the result in blob storage or a database table, and have the page poll for completion and then download the result. This pattern handles reports of any size without hitting the gateway timeout.