I'm not sure if this happens on all train systems, but on the caltrain in the San Francisco area an interesting thing happens during delays. This morning there was a delay towards the beginning of the line due to some track maintenance. Total delay? About 10 minutes.
But than an interesting development was announced - that the train would be able to make up the lost time and make the other stops pretty much on schedule. So an interesting question was brought up: if the train is indeed capable of traveling faster than it normally does, why does it not do this by default and lessen everybody's commute time by a few minutes? If they were to do this, then riders would generally have a better user experience on a daily basis.
When there were delays however, these riders would have a horrible experience: being late to work, meetings, transfers, school, etc. With the time buffer in place, caltrain is able to absorb situations that are out of its control without affecting overall experience for the commuters.
In other words, this is an example of setting the bar lower so that you're always able to achieve it. Kind of a sneaky way to win but it's probably not a huge deal to most people.
Does this kind of behavior translate well to the web? I'm not so sure it does.
You can't just normally slack off on performance in order to cover yourself in dire situations that "might" happen. An added element is that of] competition on the web. Caltrain is lucky to be the only train in town. If it was typically slower than competitors, what do you think their normal ridership would be?
The key to handling bad situations without upsetting your users is proper messaging. Be transparent and explain why your site is down. Notify users well in advance of scheduled downtimes. Continually monitor performance and forecast future server capacity needs.
