Loading
expand the downtime range from the time of the database failure
The argument here is that this shows up as "resolved in N hours", and we should be honest that the outage actually started when we started losing data. Another way to put this would mark the upgrade time (2023-10-31) as the start of the outage, but I think that would be slightly less honest, as that's just when the service was *visibly* down: all data in the four days preceeding that are still lsot. See: team#41388