Sometimes a down-time event is recorded due to misconfiguration internally to the url that uptime robot checks, however the actual service remains accessible. This is especially true for internal processes whose status is exposed via another mechanism.
In this case the actual service is still “up” but uptime robot doesn’t give us a way to either remove or disclude a specific event from our statistics.
We’re trying to improve end-user transparency, however when something like this happens it “dings” our statistics even though no actual down-time occurred.
There are even cases where the ISP that serves us has their own issues, which are beyond our control. Again, the service is up and still accessible, but the connection between us and uptime robot is down.
Adding a way to flag or remove a specific event so it does not ding statistics would give a better picture to end-users.
I totally get your point. However, allowing to remove down times might be tricky, because anyone can easily manipulate their stats, so the trustworthiness of UptimeRobot provided stats may be degraded.
Wouldn’t be better to communicate such cases via comment on incident? Or, maybe if the outage is short, to have a possibility to not display incidents shorter than 5 minutes, for example?
its true that it could be used for stat manipulation but there are other ways for a malicous vendor to fake that sort of thing (monitoring different services to what they claim, resetting their stats, simply making stuff up instead).