To pinpoint the root cause of a network outage during peak hours quickly, I’d start by checking network monitoring tools and logs for anomalies or alerts that occurred before the downtime. Verifying whether the issue is localized or widespread helps narrow the scope. Testing connectivity with diagnostic tools like ping, traceroute, or nslookup identifies potential bottlenecks or failures. I’d review the status of critical components such as routers, switches, and servers, and check for recent changes or updates that might have triggered the issue. Collaborating with the team ensures a comprehensive investigation, enabling a swift resolution while minimizing disruption.

To resolve issues, you need a good documented network layout to know where what is connected. Then, as Andreas mentioned, the most important is to recover and bring operations back to run to not have business impacted to long of this outage. After the incident, root cause must be done to identify the problem and take next steps to a) improve and b) to make things more visible for supporting application in case of failure.

During critical network issues, I stay calm and methodical by first checking hardware and recent configurations for potential faults. I use diagnostic tools like PRTG or traceroute to isolate the problem, focusing on key nodes and bottlenecks. If necessary, I roll back recent changes and switch to backup systems to restore service quickly. Clear communication with stakeholders and thorough documentation help streamline the process and guide future prevention strategies.