I built Gitae because I kept running into the same practical question: is the website actually down, or is the problem only on my side?
A single browser tab is a poor diagnostic tool. A page can fail to open because the origin is down, but it can also fail because of DNS, an HTTPS certificate problem, routing, a firewall rule, a closed or filtered port, an ISP issue, a VPN path, browser state, or a local cache. The visible symptom is the same: the site does not load. The action you should take is completely different.
That was the problem I wanted Gitae to solve. Not “give me a green or red badge,” but help me narrow the failure down to a layer I can investigate.
The problem I actually wanted to solve
Most simple website checkers answer one narrow question: did this URL return a response from one place at one moment? That can be useful, but it is not the same as diagnosing an outage.
If DNS is wrong, restarting the application will not fix it. If HTTPS is failing because of a certificate problem, changing page content is irrelevant. If a TCP port cannot be reached, the server itself may still be running. If the site opens from an external server but not from my own connection, the failure may be somewhere between my network and the destination rather than on the application server.
So I designed Gitae around a more useful mental model: a website is a chain of dependencies, and each check gives evidence about one part of that chain.
An external viewpoint, not an oracle
Gitae runs checks from my own VDS servers in Moscow and Helsinki. That matters because it gives me viewpoints outside the computer and network where I first noticed the problem.
If a site fails locally but responds from both VDS locations, that is useful evidence that the origin is not universally unreachable. It pushes the investigation toward local DNS, an ISP route, VPN behavior, browser state, a firewall, or another path-specific problem. If the site also fails from the remote probes, the case for a server-side, DNS, certificate, routing, or wider network problem becomes stronger.
But remote checks are not automatically “more reliable” than local checks, and two VDS locations do not represent the whole internet. A site can be reachable from Moscow and Helsinki and still fail from another country, ISP, CDN edge, or network. I treat the remote result as another observation point, not as a global verdict.
What Gitae checks today
The current version combines several tools that I normally want when I am trying to understand where a failure is happening:
- Website check — checks whether a URL responds from an external server.
- SSL check — inspects HTTPS/TLS certificate status and certificate-related problems.
- DNS check, nslookup, and dig — help inspect how a domain resolves and what DNS records are being returned.
- Reverse DNS and IP check — expose IP information and PTR/reverse-DNS data.
- Domain info and domain age — provide basic domain metadata.
- Port check — tests whether a target port is reachable from the probe location.
- Find your IP — shows the public IP address visible to the service.
- Ping and traceroute — provide network-level signals about latency, packet loss, and the path toward a host.
- Hosting check and CMS detection — surface infrastructure and technology signals that can help with identification.
I deliberately think of these as signals. Some are direct observations; others are inferences. A PTR record does not prove who owns a server. CMS detection based on public fingerprints is not proof of the exact software stack. A port that is unreachable from one probe may be filtered rather than truly closed everywhere.
How I interpret the results
The value comes from combining checks instead of reading each one in isolation.
For example, if DNS returns the expected address, the HTTPS certificate is valid, and the website responds from both external VDS locations, but I still cannot open it locally, I would look much harder at the local path before touching the server. In the opposite direction, if DNS resolution is inconsistent or the remote website check fails as well, there is more reason to investigate the infrastructure side.
Ping and traceroute also need restraint. ICMP can be filtered or rate-limited. A missing traceroute hop does not automatically mean that hop is broken, and a host that does not answer ping can still serve HTTPS normally. These tools are useful because they add context, not because they produce a single definitive diagnosis.
This is the main engineering principle behind Gitae: one successful check does not prove the whole system is healthy, and one failed check does not tell you the cause by itself.
Why availability matters for SEO
I also care about this from the SEO side, but I try to be precise about what availability data can and cannot tell me. A technical outage is not the same thing as a ranking problem. Crawling is not indexing, and indexing is not traffic.
What can be said safely is that if a crawler cannot reach the site because of DNS, network, or server errors, it cannot successfully fetch the affected content at that time. Google documents that network and DNS failures are treated similarly to server-side 5xx errors for crawling, and prolonged unavailability can affect crawling and indexed URLs. That does not mean every short outage causes an SEO loss, and a diagnostic tool cannot prove that an observed traffic change was caused by downtime.
For users, the logic is simpler: if they cannot reach the site, they cannot use it. Depending on the site, that can mean lost sessions, leads, conversions, or revenue. Again, the diagnostic result identifies a technical symptom; it does not calculate the business impact.
A practical order for debugging a “down” site
The workflow I want from a tool like Gitae is straightforward:
- Confirm the symptom from another network. Check the URL from an external probe instead of assuming the local browser represents everyone.
- Check DNS. Confirm that the domain resolves and that the returned records are what you expect.
- Check HTTPS/TLS. Look for certificate validity or connection problems.
- Check the required port. Verify reachability from the probe location.
- Compare network signals. Use ping and traceroute as supporting evidence, not as a pass/fail oracle.
- Look at IP, reverse DNS, hosting, and CMS signals. These can help confirm that you are reaching the infrastructure you think you are reaching.
- Only then narrow the investigation. Decide whether the strongest evidence points toward the application, server, DNS, network path, or local environment.
This order is not a protocol and it will not fit every incident. It is simply a way to avoid the mistake I wanted to eliminate: changing the wrong layer because the only information I had was “the site does not open.”
Built for real use first, monetization later
Gitae is not monetized at the moment. I built it first for myself because I wanted a fast way to check a site from outside my own machine and then move directly into DNS, certificate, port, and network diagnostics without jumping between unrelated tools.
The current goal is to make the diagnostics more useful and see whether the project can attract organic traffic through SEO and real demand. If it reaches even modest traffic, I want to add automated website monitoring with instant messenger alerts. That would extend the same idea from manual diagnosis to detection: notice that something became unavailable, then give the owner enough information to start investigating quickly.
The part I want to keep simple
The core idea has not changed. “Up” and “down” are symptoms, not explanations.
DNS, HTTPS/TLS, routing, ports, hosting, the application, and the user’s own network can all affect what looks like a simple availability problem. Gitae does not magically identify every root cause, and those external VDS locations cannot tell me what the entire internet sees. What it can do is give me several independent pieces of evidence in one place.
That is the tool I wanted for myself: something that helps me move from “the site is not opening” to the much more useful question, “which layer should I investigate next?”