Probability of server being down, knowing only uptime So I am working on project where I am monitoring server uptime/downtime. I have logs that track server uptime. Basically uptime is checked every 15 minutes. The value is total uptime (so if a server has been up for 45 minutes than that it the value that is recorded). We do not track downtime, but when a server goes down, the value for uptime resets to 0 when the server comes back up.
Here is my problem.
Event 1: uptime= 45 minutes 3:00 PM
Event 2: uptime= 11 minutes 3:15 PM
Event 3: uptime= 3  minutes 3:30 PM
Event 4: uptime= 7  minutes 3:45 PM
That means somewhere between 3:00 and 3:04 the server was down. It could have been 3:01, 3:02, etc. We don't know, all we know is that the server came back up at 3:15.
Now for my question, how do I compute the most probable percent down time? I feel like this is a lot more simpler than I'm making it.
Thanks everyone
 A: For calculating the probability it doesn't matter exactly when the server was down, just how long it has been down over a period of time.
There's nothing in your question that allows us to say anything about the length of the downtime, but it has been down at least three times (between each consecutive event), if we assume (rather randomly) that it was down for 1 minute each of those times, it's been down for 3 minutes over a period of 90 minutes (at 3:00 PM it has an uptime of 45 minutes, so it has been up since 2:15 PM), giving a probability of it being down of:
$$
\frac{3}{90}\approx 3.3333333\%
$$
A: Your example server seems to be down quite often. If we assume the downtime is always mostly the same $t$ minutes (or at least has an expected value of $t$ minutes) and it is extremely unlikely to have two down events within the same 15 minute window (this might be doubtful with your example data, but should be tur for a real-life scenario) then the first uptime measurements (i.e., uptime reports below 15 minutes) should have an expected value of $\frac{15-t}2$. Observing sufficiently many such events may give an estimation for $t$. However, this requires many observations especially if $t$ is small.
On the other hand, if $t$ is not very small compared to the 15 minute window, you may occasionally observe it down during your periodic probing, which may help with the statistics (e.g., if the downtime is typically 5 minutes, about one out of three events should lead to a failed probing).
Nothing of this helps with the individual events (apart from the obvious upper bounds from the preceding known-good probing). I would generally recommend a technical over a mathematical approach here: As the downtime seems to be related to server restarts (as opposed to, say, network interruptions), there should be suitable info findable in the server logs, either e.g. web server access log entries that are generated much more often than your 15 minute probings or even explicit messages a la "System going down for reboot". In fact, if there is no log entry about the system going down because the downtime occurs due to unexpected outages, you should rather investigate the causes than try to measure/guess the lengths of downtime. For embedded systems without much logging capacity, snmp traps might be used for similar purpose.
