> When you're not sure if a fix you're trying will succeed or not, that's not the time to say "It'll be resolved in 15 minutes." Yes. That's what I said: Provi

> When you're not sure if a fix you're trying will succeed or not, that's not the time to say "It'll be resolved in 15 minutes." Yes. That's what I said: Provide estimates when you can make them. > As a general rule I'd say not pretending to have knowledge of the future is humility. Yep, never suggested otherwise. Which is why I would never have said what you said above. > Service will be restored to normal at 3:15PM We expect service to be restored by 3:15PM. > It'll be resolved in 15 minutes. We'll have an update in 15 to 20 minutes. Both of your statements lacked that humility. > I envy the person who has always understood exactly what course of action they should take -- and exactly how long that fix will take -- before they've had even a few minutes to investigate the problem! What a perfect tech stack and perfect knowledge that person must have. They probably don't have any downtime in the first place though, since they know every bit of their application's state at all times anyway. Your envy is appreciated. I've never needed the knowledge you think I need to provide estimates on either when I think it will be fixed, or when I'll have an update. That you think that's required is a bit troubling. But hey, you don't have to provide updates, estimates, and can continue to only provide 100% assurance with second level accuracy all while ignoring customers needs.