It is common to load one website successfully while another fails, even when your Wi-Fi is fine. Internet access is a chain of systems, and a failure in one segment can affect specific services without disconnecting everything.
Understanding where failure can happen helps you troubleshoot faster and communicate better. Instead of saying "the internet is down," you can identify whether the issue is likely DNS, server availability, or application-level errors.
Different layers can fail independently
Your local network can work while a target site has server overload, misconfiguration, expired certificates, or dependency failures. Content delivery networks and DNS providers can also have regional incidents.
This layered architecture is why broad statements are often inaccurate. A single app outage does not imply full connectivity loss. A DNS problem can prevent a hostname from resolving, but testing a raw IP is not a universal substitute: HTTPS certificates, virtual hosting, and Server Name Indication often require the original hostname.
Quick checks with curl and response status
A basic curl request can show whether the host responds and which status code is returned. This does not solve the outage, but it narrows possibilities and gives better evidence for support or incident channels.
The shell snippet uses a public placeholder domain and does not require credentials. It prints headers so you can inspect HTTP status and server responses safely.
curl -I --max-time 10 https://example.comProgrammatic health checks in JavaScript
Applications often run periodic checks to track uptime and alert teams when status changes. Good checks include timeouts and clear logging so failures are detectable instead of silently hanging.
The JavaScript example is illustrative. It requests a health endpoint, records status and latency, and handles errors without exposing secrets or private infrastructure details.
async function checkHealth(url) {
const start = Date.now()
const controller = new AbortController()
const timeout = setTimeout(() => controller.abort(), 5000)
try {
const res = await fetch(url, { signal: controller.signal })
const latencyMs = Date.now() - start
return {
ok: res.ok,
status: res.status,
latencyMs
}
} catch (error) {
return {
ok: false,
error: error instanceof Error ? error.message : "Unknown error"
}
} finally {
clearTimeout(timeout)
}
}
checkHealth("https://example.com")
.then((result) => console.log(result))When one site fails but others work, think in layers. A few simple checks can distinguish local connectivity problems from remote service outages and reduce guesswork.
Back to all writing