The site is suddenly down and I don't know servers
Author: OpsMate team
Updated
You do not need Linux or SSH to start. Use only cloud accounts you are allowed to access.
Short answer: When the site is suddenly down and you do not know servers, do three things that need neither Linux nor SSH. Switch networks and see whether it is down for everyone. Open the cloud console and check whether the instance is still running and whether the security group allows traffic. Write down the time and what the page shows, then call someone. After you can log in, follow a fixed order.
Three steps you can do without Linux or SSH
A phone or your own computer is enough. You do not log in to the server.
- Switch networks. Is it down for everyone?
Open the site again on mobile data, and ask a colleague to try another network. If it fails only for you, check local DNS, a proxy, and the browser cache. Do not reboot the server yet. - Open the cloud console. Is the instance still running?
See whether the status is Running, whether the public IP is still there, and whether the security group or firewall allows 80/443 or your app port. If the instance is stopped, suspended for non-payment, or the security group blocks the ports, neither a panel nor SSH can get in. Fix that in the console first. Use the console VNC or serial console when you need to see the screen. - Write down the evidence, then call someone or learn how to log in.
Note roughly when it started, who cannot open it, console screenshots (instance status and graphs), and whether the page shows a timeout, a 502, or a certificate error. If your own computer can run a check, also record one outside result on that computer (replaceexample.comwith your domain):
Run these on your own computer, not on the server. Save the status code and thecurl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' --max-time 10 https://example.com/ dig +short example.com Adigoutput as-is. Cover internal addresses and customer information before you share them.
Where to go after these three steps
- You can already SSH and log in: continue from step 1 of Site down at 2 a.m., in the 15-minute order. Confirm the impact from outside, see whether the machine is alive, check the entry point and the app, read only the logs from the failure window, and write three lines before you change anything.
- You cannot manage a server at all, and you are not sure a panel is the next step: see I can't manage a server. What should I do?
- Someone else built the machine, and you do not have a one-page inventory yet: see Inherited a server: what to check first when you have no ops hire.
If you still cannot log in, hand the notes from these three steps to the person who built it, a per-incident consultant, or a colleague. A time and a screenshot are more useful than saying only that the site is down.
Try it (optional)
Later, if you can SSH and want the terminal and a plain-language question on the same page: OpsMate puts an SSH terminal and AI on one page, and you can still type commands yourself. Free includes 500 AI calls per month and unlimited servers. The desktop app keeps credentials on your machine by default; SSH private keys and passwords added in the web console are stored encrypted. Each time you ask the AI for help, recent terminal output is sent to the cloud AI along with your message, so remove sensitive information first. Commands that fail the safety check are blocked and never run. Low-risk fixes run automatically by default, and every step is logged.
Need help interpreting the evidence?
OpsMate (itops.sh) puts your SSH terminal and AI on one page, and you review the evidence. Each time you ask the AI for help, recent terminal output is sent to the cloud AI along with your message, so remove sensitive information first.
Start free Desktop with local credentials