Interrail web site: unable to sell seat reservations in a variety of ways

Repeatability is a perennial software engineering concern, so it may worry the team at interrail that their web site, in failing to sell seat reservations, does so in a slightly different way on different browsers.

This morning, on chrome, we have this:

The button has not been pressed.  It is never activated and says "Please wait", and is permanently in a faded state indicating non-activeness.

On firefox, and with encouraging consistency, we still have:

The "Please wait" on this was also never working.

But, I should warn you, this is no time for complacency.  On the Android browser (also "chrome"), the login worked, and it was not until a subsequent stage that it became impossible to complete the reservation:

In this case, the search button has been hit, but the results never come.  Plenty of effort has been put into the "user experience" that happens while the results don't come.  There are whizzy things going around, and gray templates, just ready and primed for the information to load.  But it never does.  This on a fast hotel wifi connection.

In the end, reservations are available at the station, the queue is not too bad, and there are staff to help with the deep screen navigation, and the funny separate machines that accept cash, and that the other machines hand off to.

A few years ago a friend challenged along the lines that: I was exaggerating about web sites not working, and a lot of the time they work fine.  This does raise the question of how reliable a web site, providing a real service that someone might want to rely on, has to be, to "work".  Doing its thing once does not make it a working web site, if the probability of success was 80%, but depending on it would require 99.9% probability.  For Interrail, a service promising "buy your pass, and it's easy to use, including making seat reservations", 99.9% probability is about right.  In my experience, they are at around 30% probability.

By the way, how is availability quantified across the full range of values, including very high, and very low?

It seems clear that four-nines is one order of magnitude lower than five-nines.  It's whatever it is, 50 minutes downtime per year instead of 5 minutes.  Whatever cost comes from unavailability is related to the downtime (separate from whether this cost is linear or not with the downtime).

At the other end of the scale, consider the difference between a service available 0.1% of the time vs 1% of the time.  Whatever value can be eked out when it's available, there is ten times as much time to do this in in the case of 1% than in the case of 0.1%.  At this end of the scale, it's the uptime, not the downtime, that matters (or the probability of success, rather than failure).  The downtime, or failure probability, do not matter at this end: there is not much difference between 99.9% and 99%.  It doesn't make sense to talk about a 1e-12 ("never") service being "only around 1%p worse" than a 1e-2 ("1%") service, even tho this is the difference in their probabilities of failure.  The latter one will eventually work if you keep trying, but the former won't.  At very unreliable scales, the probability of success dominates; at very reliable scales, the probability of failure dominates.

Interrail, at 30% probability, exists in between these poles.  It's not reliable enough to depend on, but it's enough of a shot that you might give it a go, if you have no better options.