When a server is unavailable, separate the customer-visible symptom from the possible cause. A failed website, an unreachable SSH port and a powered-off virtual machine are different incidents. Clear evidence helps support investigate the correct layer and reduces unnecessary restarts.
IN THIS ARTICLE
01 Establish the scope
- Check whether one application, every website or all access methods are affected. Test from a second network. Record the first failure time and your timezone.
- Review the service status and any maintenance notices available in the client area. If your service includes a server console, check whether the machine is running without changing its configuration.
- Look at recent monitoring for CPU, memory, disk usage and network activity. A full filesystem can break databases, mail and logging even while the server remains powered on.
- If you still have permitted access, review relevant application and system logs. Preserve the error message and recent change history. Do not remove logs to make the error disappear.
- Submit a support ticket against the affected service with the server ID, domains, failing ports or URLs, timestamps and diagnostic results. State whether customer transactions or business email are affected.
02 Choose recovery actions carefully
A graceful service restart may be appropriate after identifying a stuck process. A hard power cycle is more disruptive and can interrupt database writes. Reinstalling an operating system or restoring a snapshot can replace production data. Use these actions only with an understood recovery plan and the permissions allowed by your service.
If the server may be compromised, preserve evidence and ask for containment guidance. Repeatedly deleting suspicious files can hide the entry point, while leaving exposed credentials active can allow the attacker to return. Do not post customer data or secrets in screenshots.
How do I confirm that a server incident is resolved?
After access returns, test the website, login, database writes, mail and scheduled jobs. Check whether an interrupted job needs a controlled retry. Monitor the original failure condition over time and confirm that backups resume successfully.
Keep a short incident record with the cause, actions taken and follow-up work. Any service-credit request is reviewed under the applicable service terms and exclusions; an application error is not automatically a qualifying infrastructure outage. Retain the times and evidence needed for that review.