Re:Outlook is down, and so is Microsoft's status page
by hgomersall on Friday November 13, 2026 @06:58AM
(#50482257)
Right, rebooting only really makes sense if you understand why the reboot is going to fix the problem. As in, corrupted volatile state is reasonably fixed with a reboot. Any hardware issues or persistent state problems could well get worse.
Re:Outlook is down, and so is Microsoft's status page
by Merrill on Friday November 13, 2026 @07:05AM
(#50482337)
The following is a few decades old --
A physicist, an engineer, and a computer programmer are driving down a steep mountain pass when the car’s brakes fail.
The car speeds out of control around sharp turns, nearly flying off the edge before they miraculously manage to skid to a stop at the bottom.
Shaken up, they discuss what to do next:
• The physicist says: "We need to calculate the friction coefficients in the brake pads and model the temperature rise to figure out why they failed."
• The engineer says: "I have a few tools in the trunk. I’ll take a look underneath and see if I can fix the mechanical failure."
• The programmer says: "Why don't we get back in and see if it's reproducible?"
Re:Outlook is down, and so is Microsoft's status page
by electroweak on Friday November 13, 2026 @08:12AM
(#50483041)
But these intermittent failures lead to delays and worse. The sheer cost of repeat events leads to action. If deferrable at all the standard troubleshooting is mostly remove and replace. The repair and reliability processes identify these rogue units fairly fast and the actual rates of that in a well functioning airline are very low.
Re:Outlook is down, and so is Microsoft's status page
by SoftTalker on Friday November 13, 2026 @11:21AM
(#50485753)
Yes, I remember a flight that sat at the gate past departure time, the explanation to the passengers was that some essential piece of equipment wasn't functioning, they had tried restarting it, and it was going to be replaced. About 30 minutes late, we were on our way.
I would argue a "just reboot it" culture leads to more problems -- engineers should be empowered to diagnose problems before they become catastrophic. In the world of software we even have mechanisms for extracting data from failed systems to root cause them later, and yet most people do not take that step before "just reboot[ing] it".
[1]: AirAsia 8501, Lauda Air 004, and SmartLynx Estonia 9001 come to mind.