Is It Down for Everyone or Just Me?
Free online Is It Down for Everyone or Just Me? that runs directly in your browser.
-
1Enter data
Enter content, paste text or load a file from disk. -
2Click the button
The tool will immediately process your data in the browser. -
3Get the result
Copy the finished text or save the file to your device.
return "Result ready in 0.1s";
}
Rate this tool:
Related tools
Other tools you may find usefulIs the website working? Check online in 12 seconds, without guessing
There are days when the Internet pretends that everything is fine... and your website just disappears from people's eyes. This tester answers simply:whether the problem is on the server side, DNS, SSL, or maybe on your. You enter the address and you get a clear verdict + technical tips that can be passed on to the hosting company without the explanation "something isn't working".
What exactly do we check and why does it matter
The typical "the website doesn't work" mixes various problems that look identical at first glance: white page, timeout, browser error, sometimes looping redirections. That's why a good test doesn't end with one ping. This monitor breaks the topic down into layers: firstwhether the domain leads anywhereat all, thenwhether the server accepts connections, and finallywhether the application returns a reasonable HTTP response.
1) DNS - does the domain lead anywhere
If DNS is down, the rest is irrelevant. The website may "exist", the server may be working, but the user will not be able to find it because the browser does not know which IP address to go to. The DNS result is the first red flag: when there is an error, records, change propagation or a temporary failure of the DNS operator are most often to blame.
In practice: if DNS does not respond or returns empty records, there is no point in looking for the problem in WordPress, plugins or code - that's a different story.
2) TCP 80/443 - whether the server accepts connections
Port 80 (HTTP) and 443 (HTTPS) tell whether the server is "listening at all". You may have the correct DNS, but a firewall, network failure, reverse proxy misconfiguration or connection limit will take its toll. This step is very helpful when HTTP shouts timeout - because then you immediately know whether it is an application problem or "you are not reaching the server".
If 80 works and 443 doesn't - this is often a clue: SSL, certificate, HTTPS configuration, or block on 443.
3) HTTP - response code and time you feel in your fingers
The HTTP code (200, 301, 403, 404, 500...) is like a diagnosis on a piece of paper: short, but specific. This is where you find out whether the website actually displays the content or redirects it, whether the server has an error or is blocking access. Additionally, you get times along the way (DNS lookup, connect, TTFB, total). This makes it easy to distinguish "the site is working, but it's slow" from "the site is not responding."
And if you turn on redirect tracking, you'll see where the user ultimately goes - without manually clicking and guessing whether it's a 301, 302, or a loop.
4) Deep dive - SSL, security and quick SEO preview
When the website is online, we add the "is it healthy" layer: SSL certificate (who issued it, valid until when, how many days left), basic security headers (HSTS, CSP, X-Frame-Options, etc.) and a preview of what Google often sees first:title i meta description.
This is not a full SEO or security audit - rather a quick test that will catch typical shortcomings and will allow you to set priorities.
How to use the tool to make the result truly reliable
Most false alarms come from small things: an incorrectly pasted address, the lack of "https", a typo in the domain, or a website running only on one version (www vs. without www). Therefore, it is worth approaching the test as a short procedure: first a simple address, then possibly checking redirections and comparing variants.
- Enter the domain as the user sees it.If people go to "example.com", don't just test some long URL with parameters - start with the basics.
- Enable redirect tracking when you suspect 301/302.This helps with migrations, HTTPS changes, transitions to www or without www.
- Compare results for http and https versions.It seems obvious, but surprisingly often HTTPS breaks first (certificate, chain, configuration).
- Pay attention to the times (TTFB and total).If the total increases and the connect is fast - the problem is "upstream" (application, database, cache, overload), not in the link itself.
Interpreting the results without technical gibberish
The verdict is simple:ONLINE, OFFLINEorUNKNOWN. But the most interesting thing happens in the details: they tell who and what to report and how long it may take. Below you have a "cheat sheet" in human language.
| What do you see in the report | What does it usually mean | What to do next |
|---|---|---|
| DNS: error / no IP | Domain does not point to the server or DNS change is in progress | Check A/AAAA/CNAME records, wait for propagation, ask DNS operator |
| TCP 80/443: no connection | The server does not accept connections, the firewall is blocking, network failure | Contact the hosting / admin, check the firewall, limits and machine status |
| HTTP: 200 | The website is working (at least in the HTTP layer) | If "something is wrong", the problem is content/application (e.g. errors in the middle of the page) |
| HTTP: 301/302 | Redirection (often normal) | Enable redirect tracking and check the final address; watch out for loops |
| HTTP: 403 | Access blocking (WAF, rules, geoblock, authorization) | Check security rules, whitelist, server/proxy configuration |
| HTTP: 404 | Server is alive, but resource does not exist | Validate URLs, routing, redirects, .htaccess rules |
| HTTP: 500/502/503/504 | Application error or problem along the way (proxy/gateway) | Server logs, load, backend errors, service status; report to the hosting with the code |
| SSL: expired / missing | HTTPS is not secured properly | Certificate renewal, proper chain installation, force HTTPS |
| Security headers: missing | The website is working, but has a simple security configuration | Set HSTS, CSP, X-Frame-Options, etc. depending on the project |
Why do you need a speed rating if it's not PageSpeed?
This rating is "utility", not marketing. It is not intended to pretend to be an audit, but to quickly show whether the server responds like a sprinter or like someone who is just looking for keys. When you see an A/A+ rating and you still have the impression that the website is sluggish, the problem most often lies in the browser's rendering (heavy scripts, images, fonts). However, when you see B/C, and especially a high TTFB, it's usually a sign: the backend, cache, database, overload, or external integrations are holding the response.
In short:is not a "ranking", but an alarm signal. One that you can show the hosting guy and say, "it's lagging here."
When is this tool most useful
The best thing about this test is that it works for both the site owner and the person who "just has a report". In practice: support, webmaster, marketer, or even someone who just wants to check whether the failure is global or local.
The store stops loading the cart or checkout. Instead of "works for me", you have HTTP code and response times that show whether the problem is on the server side.
Change of hosting, switch to HTTPS, new DNS. You see the final URL after redirections and catch loops before the customer does.
Untrusted certificate message? You check when it expires and whether it is active at all before you start putting out the fire.
Title and meta description preview helps catch situations such as: missing title, strange characters, unwanted redirection to another domain.
Report from a customer: "the website is not working." In 30 seconds you have the data to respond and you know whether to escalate to hosting.
Quick sanity check after deployment: whether the server returns 200, whether it does not spit out 500/502 and whether HTTPS is still straight.
The most common reasons that a website "does not work" (and is not dead at all)
The paradox of the Internet is that a website can be online and at the same time "not working" in the user's opinion. Example? Code 200, but the application displays an error inside the page. Or a 301 that leads in circles so the browser gives up. Or a 403 because the security filter found your traffic suspicious.
- Redirections after changing domain/HTTPS - the final address is different than you think.
- Expired certificate - the website exists, but the browser is intimidating.
- Firewall/WAF blocked - code 403 for some users or countries.
- Server congestion - increasing response times, then 503/504.
- Incorrect DNS after changes - some see the new server, others still see the old one.
- Gateway/proxy on the way - 502/504 even though the application is alive inside.
FAQ - the questions people always ask (and rightly so)
Does the "ONLINE" result mean that the website is definitely working properly?
It means that the page responds at the network and HTTP level - that is, the user is able to get a response from the server. This is a great first filter, but it doesn't rule out problems "in the middle," such as content errors, broken features, JavaScript errors, or login issues. If you have 200 and reasonable times and users still report problems, it is worth checking a specific subpage or scenario (cart, form, panel).
What does "UNKNOWN" mean and when does it happen?
"UNKNOWN" is when the test cannot clearly determine whether the service is up or down - usually because the response is unusual, unstable, or blocked. It can happen with strong security measures (e.g. protection against bots), with temporary problems along the way or when the server returns ambiguous errors. Then the details are important: DNS, ports and HTTP code tell you which way to go.
Why do I get 301/302 if the "page won't open"?
Because redirection may lead to the wrong place or create a loop. The user then sees a message such as "too many redirects" or a page that ends with a timeout. Enabling redirection tracking allows you to see the final address and quickly detect whether the problem is, for example, a conflict between www vs. no www, HTTP vs. HTTPS, or incorrectly set rules on the server.
Does the tool also check SSL and when will I see this data?
Yes - if the website is available and an HTTPS connection can be established, you will receive basic information about the certificate, including the validity date and the number of days until expiration. This is especially useful because SSL can "overturn" a business in one day: users are afraid, browsers warn, and advertising and SEO can backfire.
The result shows 403 - does this mean the site is hacked?
Usually not. 403 means "access denied" and most often results from configuration: firewall/WAF rules, server-level blocking, geographical restrictions, lack of authorization or incorrect permissions. Of course, if the 403 appeared suddenly and affects everyone, it is worth checking whether the security rules have changed, but the 403 code itself is not proof of hacking.
Can I check out a site that has anti-bot protection (e.g. challenge)?
Depends on the type of protection. If the website requires interaction (challenge, captcha, dynamic scripts), the test may receive a response different from that of a regular user and the result may be ambiguous. In such cases, treat the report as a network-server diagnostic: DNS, ports, and the underlying HTTP response are still valuable, but full "does it work for a human" verification may require a browser test.
How can I report the problem to the hosting as soon as possible to avoid the "please give me more data" response?
Send three things: the domain you are testing, the HTTP code (or no response information) and times (especially total and TTFB), plus whether port 80/443 is reachable. Hosting and administrators love specifics - it shortens email ping-pong. If you also have information about DNS (whether it returns an IP), even better, because it is immediately clear whether the topic concerns the server or domain settings.
Finally: if you want "it works" to mean "it works"
A one-time test is great, but real peace of mind comes from habit: checking the website after DNS changes, after implementation, after certificate renewal, after a major marketing campaign. The Internet is merciless: when something goes wrong, the user doesn't wait - he simply disappears. And you are left with the question: "Is it the server's fault or mine?" It's better to have the answer right away.
Run accessibility analysis