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).
What about when a monitor shows as down for 18 hours but it was actually an issue with the monitor and not what was being monitored?
If you get DNS failure status, pause and resume de monitor. sugestion by chat support
Hey everyone, we’ve released an option to exclude incidents from reports! This feature allows you to hide an incident from all your stats.
For now, it doesn’t affect status pages, but we’ll be adding that in future updates.