downWebsite not working? Check whether the problem is local or widespread
A practical sequence for comparing service incidents, public website responses, browsers, and networks without losing unsaved work.
Start with the exact failure
Record the time, address, action, and error message. A login failure, a slow page, and a connection error point to different parts of a service. Save unsent work before refreshing or closing a tab.
Compare current evidence
Search for the service on Iszdown and compare the incident timeline with the time your problem started. An active provider incident is stronger evidence of a wider disruption than a single failed visit. Check which features and regions are named; another product from the same company may still work.
Check public access
Use the website checker to see whether the public endpoint responds from our US server. A response confirms that particular request only. Automated-access restrictions are inconclusive, and a working homepage does not test your account, payments, or an API.
Compare a browser and a network
Try a private browser window or another browser. If practical, compare a different trusted network. If the problem follows one browser, review extensions and saved sessions; if it follows one network, check the connection or contact its administrator. Avoid repeatedly clearing data before preserving local work.
Report a useful observation
Report the affected feature, time, and error category. Keep passwords, session cookies, access tokens, private customer data, and patient information out of public reports. A support ticket for an account-specific problem belongs with the provider.