Designing Reliable Health Check Endpoints for IIS Behind Azure Application Gateway

Azure Application Gateway solely depends on health probes to figure out whether the backend instances are ready to handle traffic.

If a probe encounters any of the following issues:

• Receives a response other than a 200
• Times out
• Gets redirected
• Needs authentication

…the backend is classified as Unhealthy, halting traffic flow and leading to user errors.

It’s important to note that a healthy IIS application does not guarantee a healthy Application Gateway backend.

One of the common dilemmas teams face is when the IIS application runs smoothly, yet users sporadically see 502 Bad Gateway errors.

This usually occurs because health probes are failing, prompting Azure Application Gateway to mark the backend instances as Unhealthy and stop directing traffic to them.

The diagram below illustrates this failure flow.

Key takeaway: Most 502 errors linked to Azure Application Gateway stem from probe failures rather than application errors.

• Azure Application Gateway makes regular health checks on backend IIS instances.
• If the probe endpoint:

– Redirects to /login

– Requires authentication

– Returns a 401 / 403 / 302

– Times out
the probe is deemed failed.

• With consecutive failures, the backend instance gets marked Unhealthy.
• Application Gateway stops sending traffic to unhealthy backends.
• If all backend instances are marked as unhealthy, every client request leads to a 502 Bad Gateway error, even if the IIS service is operational.

This is why having a dedicated, lightweight, unauthenticated health endpoint is vital for maintaining production stability.

Before we dive into how to solve these issues, let’s look at the common pitfalls.

Many IIS applications:

• Redirect / → /login
• Require authentication
• Return 401 / 302 / 403 responses

However, Application Gateway expects a straightforward 200 OK response, free of redirects or authentication requests.

Keep in mind, health probes do not accept authentication headers.

Should your app enforce:

• Windows Authentication
• OAuth / JWT
• Client certificates

…the probe will ultimately fail.

Testing an endpoint that:

• Calls a database
• Conducts startup checks
• Loads configuration

can lead to intermittent failures, particularly under heavy load.

For TLS-enabled backends, probes may fail due to:

• Missing Host header
• Improper SNI configuration
• Mismatched certificate CN

Your health check endpoint should be:

• Lightweight
• Anonymous
• Fast (< 100 ms)
• Always return HTTP 200
• Independent from application logic

Here we can see the health probe architecture for IIS backends using a dedicated /health endpoint.

Azure Application Gateway consistently checks the dedicated /health endpoint on each IIS backend instance.
This health endpoint is specifically crafted to provide a quick, unauthenticated 200 OK response, enabling Application Gateway to confidently ascertain backend health while maintaining security for application endpoints.

This endpoint should:

• Bypass any authentication
• Avoid any sort of redirects
• Skip database calls

To set up a static file, follow this:

• It should be static
• Fast
• Completely loaded with zero dependencies

If your IIS site requires authentication, make sure to allow anonymous access for /health explicitly.

This sets the stage for successful probes, even when other parts of the site are secure.

HealthProb setting example

By adhering to this configuration, you ensure:

• A correct Host header
• Proper validation of certificates
• Avoidance of TLS handshake failures

• Go to Backend health
• Check that the status shows Healthy
• Ensure the response code equals 200

Expected:

Review authentication settings
Confirm /health does not redirect
Check for 200 HTTP response

Ensure that the certificate CN matches the backend domain
Activate “Pick host name from backend”
Verify the certificate is correctly bound in IIS

Limit probe complexity
Steer clear of database or service calls
Opt for static content

• Use individual health endpoints for each application
• Avoid reusing business endpoints as probes
• Keep an eye on probe failures as early indicators of issues
• Test probes following each deployment
• Keep health endpoints straightforward and uncomplicated

A dependable health check endpoint is essential when managing IIS behind Azure Application Gateway—it forms a key aspect of application uptime.

By creating a dedicated, authentication-free, lightweight health endpoint, you can considerably reduce false outages and boost platform stability.

If you’re transitioning IIS applications to Azure or dealing with unexplained Application Gateway failures, your first port of call should be your health probe—it’s often the quiet troublemaker.