I sort of resent measuring stability by measuring server uptime. Stability should be measured in service uptime. This often means putting a load balancing and or failover scheme in place. Why, Stuff happens. If you have a no downtime policy. Patching, HW failures, db failures, backup failures, power outages... becomes part of the plan. The question you should be asking your self is why things are failing. Odds are its your application, not webserver, OS, memory or what ever. My personal walk of shame includes :-O

• Is your web-app starting to misbehave after 3 weeks, and you can't fix it? Make sure you restart the application 4 AM every week.
• Can't coupe with traffic load and you can't make the application less talkative? Time for an upgrade or rather an additional server.
• IIS starts eating memory running in a .NET environment and you have mistreated IDisposable (I have never strolled down this path :sigh: and made a mess ) add a bucket of memory, restart server nightly... :doh:
• configuring backup job to run during peak hours
• not using cache, caching to much, corrupting the cache...

My point is, putting an equal sign between uptime and stability is as flawed as measuring cpu-power by MHz. It will say something about the processor but nothing about raw processing power. Or in this case, server uptime don't say much about service level from a customer point of view. /Matthew