[debug output provided]
The hosts.cfg entries are: 192.168.0.2 tesla # ssh http://tesla httpstatus=dbB;http://tesla/cgi/dbB.pl;200; httpstatus=dbC;http://tesla/cgi/dbC.pl;200;
The only difference that I know of between the monitoring servers is that monitor5 has an 'analysis.cfg' with: HOST=tesla DS http %.*http.*:sec >0.660 COLOR=yellow TEXT="Time exceeds &U at &V seconds."
With the above monitor5:analysis.cfg directive; the status is reported as yellow; without it is reported as red.
It looks like the analysis.cfg entry causes Xymon to mask the red with the yellow.
OK, *now* I understand what You were talking about with "analysis.cfg". I had not noticed that You were using a "DS" test for response-times.
There's some bad news and some good news. Both of them are that Xymon works as designed :-/ The DS checks can increase the severity of a status - e.g. from green to yellow - or it may decrease the severity, which is what happens in this case.
I can see what it is You want to achieve, and Xymon obviously does not behave the way one would expect in this case. But I am not sure what the correct solution is.
An easy fix would be to say that the "DS" rules can only increase the severity of a status, not decrease it. But I can quickly come up with a couple of scenarios where I want the severity to be reduced.
The ideal solution would be a more advanced method of giving priorities to the different information Xymon has: Whether the network test actually worked, what the response time is, what data was returned from the server ... that can get quite complicated.
I'll have to think about how to solve this.
Regards, Henrik