Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm using HAProxy 1.3.15 in a cluster, behind which I have a couple servers running IIS7 (Win2k8). Occasionally, when I check the "Status", I see that the amount of time "UP" has reset. Nothing I can see on the server indicates any sort of failure or resets, but I still find it odd.

So, I guess I have 2 questions:

  1. How does HAProxy determine if a server is "UP" for the purposes of reporting?
  2. How reliable is that uptime information?
share|improve this question
up vote 1 down vote accepted

The "uptime" is how long the server has been up since haproxy last pulled it out of rotation.

So if you have a few checks in a row that are above a certain response time, the uptime is reset.

These checks are define by the check options when defining a server:


This option enables health checks on the server. By default, a server is always considered available. If "check" is set, the server will receive periodic health checks to ensure that it is really able to serve requests. The default address and port to send the tests to are those of the server, and the default source is the same as the one defined in the backend. It is possible to change the address using the "addr" parameter, the port using the "port" parameter, the source address using the "source" address, and the interval and timers using the "inter", "rise" and "fall" parameters.

So the "few checks" are controlled by:

fall <count>

The "fall" parameter states that a server will be considered as dead after <count> consecutive unsuccessful health checks. This value defaults to 3 if unspecified. See also the "check", "inter" and "rise" parameters.

The response time or timers are controlled by inter:

The "inter" parameter sets the interval between two consecutive health checks to milliseconds. If left unspecified, the delay defaults to 2000 ms. It is also possible to use "fastinter" and "downinter" to optimize delays between checks depending on the server state :

Server state Interval used Up 100% (non-transitional) "inter" Transitionally up (going down) Transitionally down (going up), or yet unchecked "fastinter" if set, "inter" otherwise Down 100% (non-transitional) "downinter" if set, "inter" otherwise Just as with every other time-based parameter, they can be entered in any other explicit unit among { us, ms, s, m, h, d }. The "inter" parameter also serves as a timeout for health checks sent to servers if timeout check is not set. In order to reduce "resonance" effects when multiple servers are hosted on the same hardware, the health-checks of all servers are started with a small time offset between them. It is also possible to add some random noise in the health checks interval using the global "spread-checks" keyword. This makes sense for instance when a lot of backends use the same servers.

More at .

share|improve this answer
Can you elaborate a bit? What d'you mean by "a few checks in a row"? – jvenema May 23 '11 at 20:24
Links busted too now. – slm Jun 11 '15 at 23:24

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.