When a website stops loading, the first question is usually:
Is the website actually down or is something wrong with my connection?
For developers, diagnosing availability issues requires more than refreshing a browser.
A website can fail because of DNS resolution problems, web server errors, network routing issues, SSL certificate problems or even a local browser configuration.
In this guide, we'll explore several practical methods to check website availability and troubleshoot common failures.
1. Understand What "Website Down" Actually Means
A website being unavailable doesn't always mean its server is offline.
Consider these scenarios:
- The web server is running, but its database is unavailable.
- The domain resolves to an incorrect IP address.
- The server returns HTTP 503 because it is under maintenance.
- Your internet provider cannot reach the website.
- The website works from one geographic region but fails from another.
- A CDN or firewall blocks certain visitors.
This is why checking availability from an independent network is often the fastest first diagnostic step.
2. Check a Website Using cURL
One of the easiest command-line tools for checking HTTP connectivity is curl.
Open your terminal and run:
curl -I https://example.com
The -I option requests HTTP headers.
You might receive:
HTTP/2 200
content-type: text/html
server: nginx
A 200 status generally indicates the HTTP request succeeded.
However, different responses can tell a different story.
| HTTP code | Meaning |
|---|---|
| 200 | Request succeeded |
| 301 | Permanent redirect |
| 302 | Temporary redirect |
| 403 | Access forbidden |
| 404 | Resource not found |
| 500 | Internal server error |
| 502 | Bad gateway |
| 503 | Service unavailable |
| 504 | Gateway timeout |
An important point: a successful HTTP response doesn't guarantee the entire website works correctly. The page could still have broken JavaScript, unavailable APIs or login failures.
3. Measure Website Response Time
You can also measure the time required for a server to respond.
Run:
curl -L -o /dev/null -s \
-w 'HTTP: %{http_code}\nTotal time: %{time_total}s\n' \
https://example.com
Example output:
*HTTP: 200
Total time: 0.428s
*
The first value is the HTTP status code and the second shows the total elapsed request time.
If the same website consistently takes several seconds to respond, you might need to investigate server load, network latency, database performance or CDN configuration.
4. Diagnose DNS Resolution Problems
Sometimes the server is available, but your device cannot resolve its domain name.
To investigate DNS, use:
nslookup example.com
On systems with dig installed:
*dig example.com
*
If DNS resolution fails, check the domain's DNS configuration and try another trusted DNS resolver to determine whether the problem is local or widespread.
DNS-related issues can arise from expired domains, incorrect records, resolver failures or propagation delays after a DNS change.
5. Check Website Status From an Independent Server
Command-line testing is useful, but it still relies on your current network connection.
What if the problem is your ISP, VPN or local firewall?
This is where an external website status checker can help.
I built Is It Down?, a free tool that checks website availability from an independent server.
Try the tool: https://isitdown.magic2.si
You can enter a domain and get information such as:
- Live HTTP availability results
- HTTP response codes
- Server response times
- Recent uptime and response-time history
- Outage reports submitted by other visitors
The tool also provides recent checks and status information for popular websites.
Unlike checking from your browser, an independent server request helps identify whether the problem is specific to your connection.
Keep in mind that a successful test from one external server does not guarantee a website is accessible from every region.
6. Review Historical Website Availability
An important limitation of one-time website checks is that they only show what happened at the time of the request.
Intermittent outages may disappear before you start troubleshooting.
Historical information can help answer questions such as:
- Has the website been failing repeatedly?
- Did the response time suddenly increase?
- Was the service unavailable earlier today?
- Are other users reporting similar problems?
Is It Down? provides recent history, including 24-hour and 7-day views, for supported status records.
7. Troubleshoot the Most Common Problems
If an external checker can reach the website but your browser cannot, try the following:
- Open the website in a private browser window.
- Test using mobile data instead of Wi-Fi.
- Temporarily disable your VPN or proxy.
- Clear your browser's cache.
- Check your device's DNS settings.
- Restart your router if other network tests suggest a local problem.
If an external checker also reports a connection failure, investigate server logs, hosting status, DNS, firewall rules and upstream services.
A failed external check is evidence of a problem from that checking location, not necessarily proof of a worldwide outage.
8. A Practical Website Debugging Workflow
For a repeatable troubleshooting process:
Website not loading
|
v
Check from another network
|
v
Check using external server
|
v
Inspect HTTP response
|
v
Check DNS resolution
|
v
Review historical availability
|
v
Investigate the failing component
This approach can help you avoid unnecessary changes to a working server when the actual issue is local connectivity.
## Final Thoughts
Website downtime can originate from many different layers of the internet infrastructure.
As developers, we should separate HTTP availability, DNS resolution, application health and local network connectivity when troubleshooting.
For quick external HTTP availability checks, you can use https://isitdown.magic2.si.
It's free, doesn't require registration and provides a practical starting point for diagnosing website connection problems.
Have you experienced a website that worked perfectly for some users but failed for others? I'd be interested to hear how you diagnosed it.
Top comments (0)