Understanding IIS Website Limits: Connection Timeout, Bandwidth, and Connection Limits

In this article, I’m here to share insights I’ve gained from tackling various real-world challenges, where a common factor turned out to be just three IIS Website Limit settings. While these options may seem quite simple in the user interface, they can silently lead to significant issues down the line.

I’ve noticed these settings can cause timeouts, dropped connections, and puzzling performance problems, sometimes even before a request reaches your application. That’s what makes them particularly sneaky—everything seems in order at the application level, but problems are brewing beneath the surface.

The goal here is straightforward: I want to equip you to spot these patterns early. By understanding how these limits function, you can identify problems more quickly and steer clear of hours wasted on unnecessary troubleshooting.

Let’s dive into the details.

When diagnosing performance issues or unexpected disconnections in IIS-hosted applications, it’s easy to overlook Website Limits configuration.

You can find these settings under:

IIS Manager → Site → Actions → Configure → Limits

These settings play a vital role in managing how the server handles connections and network usage.

This article will focus on three commonly used settings:

• Connection Timeout
• Limit Bandwidth Usage
• Limit Number of Connections

This setting determines how long IIS will maintain a connection before it’s closed if there’s no activity or it’s incomplete.

• Default: 120 seconds (2 minutes)
• Applies to:
  • Idle connections
  • Slow uploads
  • Requests that take too long

You might notice effects in situations such as:

• API calls that take a long time
• Uploading large files
• Clients on slow networks
• Queues building up under heavy load

Common errors include:

• Client: Connection reset / cannot reach site
• Proxy: 502 / 504 errors
• Uploads: Partial uploads that fail

Consider increasing the limit when:

• Your APIs take longer to complete
• Users are uploading larger files

Think about decreasing it when:

• You notice many idle connections
• You’re dealing with slow client attacks or connection hoarding

Key Insight:
This operates at the HTTP.sys level, meaning requests could fail before reaching your application.

This setting defines the maximum outbound bandwidth for your website.

If enabled, IIS will limit speed responses.

• Great for multi-tenant servers
• Ideal in shared infrastructure setups
• Helps in preventing one application from monopolising the network

Commonly reported symptoms:

• Pages loading slowly
• File downloads stalling
• Frequent buffering in streaming
• Upstream gateway timeouts (504)

Use this setting when:

• You require fair usage across applications
• Operating within shared hosting environments

Steer clear of it when:

• In dedicated production environments
• Performance is a key priority

Important Note:
This setting doesn’t cut down server load—it merely slows down responses.

This setting manages the maximum number of concurrent connections allowed for the website.

• Enabling it via checkbox
• Once the limit is reached, IIS rejects new connections

• To avoid resource exhaustion
• To isolate noisy applications
• To maintain traffic control in shared environments

Common error patterns:

• HTTP 503 (Service Unavailable)
• Connection failures before the application processes requests

<pEven if set to unlimited:

Your system is still limited by CPU, memory, threads, and backend dependencies.

Raising this value:

• Does NOT resolve performance issues
• Could even heighten failures during high loads

Apply limits when:

• You need to enforce controlled back-pressure
• Protecting shared systems

Avoid blindly raising limits during incidents.

Always investigate:

• CPU usage
• App pool queue
• Thread starvation
• Slow downstream dependencies

When users report:

• Random 502 / 504 errors
• Upload failures
• Intermittent disconnections

Always check:

• Connection Timeout
• Bandwidth limit
• Connection cap

Because:

These settings can halt or terminate requests before your code gets a chance to execute

Understanding configuration is vital, but the real benefit lies in spotting patterns during incidents.

Here are real-world scenarios where these IIS Website Limits directly influence production systems.

• Application hosted behind:
  • Azure Application Gateway / Nginx / ARR
• Users reporting:
  • Random failures
  • Occasional API call failures

• IIS logs show:
  • sc-status = 200 (success) for several requests
• Yet users are still facing:

• Connection Timeout in IIS = 120 seconds
• Upstream proxy timeout = 60 seconds

Result:

• Proxy times out first, resulting in 504
• IIS continues processing…→ client never gets a response

Ensure timeouts are aligned between layers:

• App Gateway / Proxy timeout should be ≥ IIS Connection Timeout
• IIS timeout should match the actual request processing time

Treat timeouts as a chain, not stand-alone.

• Users uploading large files (100MB+)
• Uploads fail unexpectedly, especially from slower networks

• Upload halts halfway through
• No obvious application exception logged
• Connection abruptly closed

• IIS Connection Timeout triggered while:
  • Client is still sending the request body slowly

HTTP.sys ends the connection before the upload completes.

Consider increasing connection timeout
Simulate slow network conditions to validate

Connection timeout affects not only idle connections but also slow request body transmissions.

• Surge in traffic (due to deployment or marketing event)
• APIs begin to fail

• IIS logs show a mixture of successes and failures
• Users are confused:
• CPU usage is < 50% (not overloaded)

• “Limit number of connections” was activated
• The set value was too low

IIS started turning away new connections once the threshold was reached.

Consider raising the connection limit
OR remove the limit if it’s not needed
Check actual concurrency against the configured limit

503 doesn’t always indicate server overload; it can also mean intentional denial due to limits.

• Users reporting:
  • Slow page loads
  • Slow file downloads

• CPU: Normal
• Memory: Normal
• No thread contention detected

However:

• Response times are excessively high

• “Limit bandwidth usage” activated in IIS
• Value set too low

IIS is throttling response speeds on purpose.

Consider disabling the bandwidth limit
OR set it to a more suitable throughput

Bandwidth limit creates artificial slowness, it isn’t an actual system bottleneck.

• High traffic levels
• Some requests succeed while others fail

• Requests stall in:
• Failing before execution begins

• Requests waiting too long in the queue
• Connection timeout triggered before execution starts

Increase timeout (temporary fix)
Address root causes like:

• Thread starvation
• Slow external dependencies

Timeouts can happen even before requests are executed.

When analysing IIS-related problems, quickly connect symptoms to issues:

In actual production environments, IIS limits seldom function in isolation; they can amplify existing system behaviours.

A high-functioning system:

• Synchronises timeouts across layers
• Avoids unnecessary limitations
• Uses limits for protection, not to mask underlying issues