When hosting IIS-based applications behind Azure Application Gateway, one of the most common production issues teams face is unexpected 502 / 504 errors, even when the application itself appears healthy. In many cases, the root cause is not the application, but a misconfigured or unreliable health probe. During a recent enterprise migration of IIS applications to Azure IaaS, we observed that default health probe behavior is often insufficient for real-world IIS workloads—especially when authentication, redirects, or certificates are involved. This post walks through how to design a reliable health check endpoint for IIS, specifically optimized for Azure Application Gateway, based on real production lessons.
Why Health Probes Matter in Azure Application Gateway
Azure Application Gateway relies entirely on health probes to determine whether backend instances should receive traffic.
If a probe:
- Receives a non‑200 response
- Times out
- Gets redirected
- Requires authentication
…the backend is marked Unhealthy, and traffic is stopped—resulting in user-facing errors.
A healthy IIS application does not automatically mean a healthy Application Gateway backend.
Failure Flow: How a Misconfigured Health Probe Leads to 502 Errors
One of the most confusing scenarios teams encounter is when the IIS application is running correctly, yet users intermittently receive 502 Bad Gateway errors.
This typically happens when health probes fail, causing Azure Application Gateway to mark backend instances as Unhealthy and stop routing traffic to them.
The following diagram illustrates this failure flow.
Failure Flow Diagram (Probe Fails → Backend Unhealthy → 502)
Key takeaway: Most 502 errors behind Azure Application Gateway are not application failures—they are health probe failures.
What’s Happening Here?
- Azure Application Gateway periodically sends health probes to backend IIS instances.
- If the probe endpoint:
o Redirects to /login
o Requires authentication
o Returns 401 / 403 / 302
o Times out
the probe is considered failed.
- After consecutive failures, the backend instance is marked Unhealthy.
- Application Gateway stops forwarding traffic to unhealthy backends.
- If all backend instances are unhealthy, every client request results in a 502 Bad Gateway—even though IIS itself may still be running.
This is why a dedicated, lightweight, unauthenticated health endpoint is critical for production stability.
Common Health Probe Pitfalls with IIS
Before designing a solution, let’s look at what commonly goes wrong.
1. Probing the Root Path (/)
Many IIS applications:
- Redirect / → /login
- Require authentication
- Return 401 / 302 / 403
Application Gateway expects a clean 200 OK, not redirects or auth challenges.
2. Authentication-Enabled Endpoints
Health probes do not support authentication headers.
If your app enforces:
- Windows Authentication
- OAuth / JWT
- Client certificates
…the probe will fail.
3. Slow or Heavy Endpoints
Probing a controller that:
- Calls a database
- Performs startup checks
- Loads configuration
can cause intermittent failures, especially under load.
4. Certificate and Host Header Mismatch
TLS-enabled backends may fail probes due to:
- Missing Host header
- Incorrect SNI configuration
- Certificate CN mismatch
Design Principles for a Reliable IIS Health Endpoint
A good health check endpoint should be:
- Lightweight
- Anonymous
- Fast (< 100 ms)
- Always return HTTP 200
- Independent of business logic
|
| | HTTPS (Public DNS) v +-------------------------------------------------+ | Azure Application Gateway (v2) | | - HTTPS Listener | | - SSL Certificate | | - Custom Health Probe (/health) | +-------------------------------------------------+ | | HTTPS (SNI + Host Header) v +-------------------------------------------------------------------+ | IIS Backend VM | | | | Site Bindings: | | - HTTPS : app.domain.com | | | | Endpoints: | | - /health (Anonymous, Static, 200 OK) | | - /login (Authenticated) | | | +-------------------------------------------------------------------+ |
Azure Application Gateway health probe architecture for IIS backends using a dedicated /health endpoint.
Azure Application Gateway continuously probes a dedicated /health endpoint on each IIS backend instance.
The health endpoint is designed to return a fast, unauthenticated 200 OK response, allowing Application Gateway to reliably determine backend health while keeping application endpoints secure.
Step 1: Create a Dedicated Health Endpoint
Recommended Path
|
1 /health |
This endpoint should:
- Bypass authentication
- Avoid redirects
- Avoid database calls
Example: Simple IIS Health Page
Create a static file:
|
1 C:\inetpub\wwwroot\website\health\index.html |
- Static
- Fast
- Zero dependencies
Step 2: Exclude the Health Endpoint from Authentication
If your IIS site uses authentication, explicitly allow anonymous access to /health.
web.config Example
|
1 <location path="health"> 2 <system.webServer> 3 <security> 4 <authentication> 5 <anonymousAuthentication enabled="true" /> 6 <windowsAuthentication enabled="false" /> 7 </authentication> 8 </security> 9 </system.webServer> 10 </location> |
⚠️ This ensures probes succeed even if the rest of the site is secured.
Step 3: Configure Azure Application Gateway Health Probe
Recommended Probe Settings
|
Setting |
Value |
|
Protocol |
HTTPS |
|
Path |
/health |
|
Interval |
30 seconds |
|
Timeout |
30 seconds |
|
Unhealthy threshold |
3 |
|
Pick host name from backend |
Enabled |
HealthProb setting example
Why “Pick host name from backend” matters
This ensures:
- Correct Host header
- Proper certificate validation
- Avoids TLS handshake failures
Step 4: Validate Health Probe Behavior
From Application Gateway
- Navigate to Backend health
- Ensure status shows Healthy
- Confirm response code = 200
From the IIS VM
|
1 Invoke-WebRequest https://your-app-domain/health |
Expected:
|
1 StatusCode : 200 |
Troubleshooting Common Failures
Probe shows Unhealthy but app works
✔ Check authentication rules
✔ Verify /health does not redirect
✔ Confirm HTTP 200 response
TLS or certificate errors
✔ Ensure certificate CN matches backend domain
✔ Enable “Pick host name from backend”
✔ Validate certificate is bound in IIS
Intermittent failures
✔ Reduce probe complexity
✔ Avoid DB or service calls
✔ Use static content
Production Best Practices
- Use separate health endpoints per application
- Never reuse business endpoints for probes
- Monitor probe failures as early warning signs
- Test probes after every deployment
- Keep health endpoints simple and boring
Final Thoughts
A reliable health check endpoint is not optional when running IIS behind Azure Application Gateway—it is a core part of application availability.
By designing a dedicated, authentication‑free, lightweight health endpoint, you can eliminate a large class of false outages and significantly improve platform stability.
If you’re migrating IIS applications to Azure or troubleshooting unexplained Application Gateway failures, start with your health probe—it’s often the silent culprit.
Microsoft