A Windows website can fail at DNS, TLS, IIS or application level. Record the exact address, time and error before making changes. The same browser message can hide different causes, and restarting the application repeatedly may remove useful evidence without fixing the fault.
IN THIS ARTICLE
01 Identify the failing layer
- Try the site over a second network and check whether the error affects every page. If the domain does not resolve, investigate DNS first. If the browser shows a certificate warning, inspect HTTPS and the certificate hostname.
- Open the intended subscription and domain in Plesk. Check that hosting is active and files are in its document root. A default page often means the request reached a different site or the published output is in the wrong directory.
- Review the domain's available logs and the application's own restricted logs. Match entries to the failed request time. Keep a copy of the relevant error before uploading another release.
- For a 404, confirm that the file or application route exists. If only refreshed internal URLs fail, review the framework's IIS routing configuration rather than inventing Apache rewrite rules.
- For a 500, check recent configuration changes, the deployed
web.config, runtime compatibility and database access. Restore one known-good change at a time. - For a 503 or a stopped application, use any restart control available to your subscription once. If it immediately stops again, collect the startup error and contact support.
02 Be careful with permissions and debugging
Grant write access only to directories the application genuinely needs, such as a designated upload or cache directory. Making the whole website writable is not a sound repair. Keep production exception details hidden from visitors; they can reveal paths, database information and source-code details. Use protected logs to investigate.
How do I confirm that the Windows application has recovered?
After a correction, test the original failing URL, login, database access and file uploads. Watch for repeated errors rather than relying on a single successful refresh. If a deployment changed the database, restoring old files alone may leave an incompatible schema.
Send us support the domain, affected URL, HTTP status, timestamp with timezone and the relevant sanitised log entry. Include the runtime and most recent change. Do not attach a full configuration file containing passwords, API keys or payment credentials.