Ich habe Gitae gebaut, weil ich immer wieder vor derselben praktischen Frage stand: Ist die Website wirklich down, oder liegt das Problem nur auf meiner Seite?
Ein einzelner Browser-Tab ist dafür ein schlechtes Diagnosewerkzeug. Eine Seite kann nicht laden, weil der Origin-Server ausgefallen ist. Genauso gut können DNS, ein HTTPS-Zertifikatsproblem, Routing, eine Firewall-Regel, ein geschlossener oder gefilterter Port, der ISP, ein VPN-Pfad, Browserzustand oder lokaler Cache die Ursache sein. Das sichtbare Symptom ist identisch. Die richtige Maßnahme ist es nicht.
Genau das wollte ich mit Gitae verbessern: nicht nur einen grünen oder roten Status anzeigen, sondern die Fehlersuche auf die Schicht eingrenzen, die als Nächstes untersucht werden sollte.
Das eigentliche Problem hinter „die Website ist down“
Viele einfache Website-Checker beantworten nur eine enge Frage: Hat diese URL von einem bestimmten Ort zu einem bestimmten Zeitpunkt geantwortet? Das ist nützlich, aber noch keine Ursachenanalyse.
Ist DNS falsch, hilft ein Neustart der Anwendung nicht. Scheitert HTTPS am Zertifikat, ist der Seiteninhalt irrelevant. Ist ein TCP-Port nicht erreichbar, kann der Server trotzdem laufen. Funktioniert die Website von einem externen Server, aber nicht über meine eigene Verbindung, kann der Fehler irgendwo auf dem Pfad zwischen meinem Netzwerk und dem Ziel liegen statt auf dem Application-Server.
Darum basiert Gitae auf einem einfacheren Modell: Eine Website ist eine Kette von Abhängigkeiten, und jeder Test liefert nur Hinweise zu einem Teil dieser Kette.
Externe Perspektive statt scheinbarer Gewissheit
Die Checks von Gitae laufen auf meinen eigenen VDS-Servern in Moskau und Helsinki. Dadurch bekomme ich Beobachtungspunkte außerhalb des Rechners und Netzes, auf dem ich das Problem zuerst bemerkt habe.
Wenn die Website lokal nicht lädt, aber von beiden VDS-Standorten antwortet, ist das ein wichtiges Signal: Der Origin ist zumindest nicht überall unerreichbar. Dann prüfe ich eher lokalen DNS, ISP-Routing, VPN, Browserzustand, Firewall oder andere pfadabhängige Ursachen. Schlägt die Website auch von außen fehl, werden Server, DNS, Zertifikat, Routing oder ein breiteres Netzwerkproblem plausibler.
Externe Checks sind aber nicht automatisch „zuverlässiger“ als lokale. Zwei VDS-Standorte repräsentieren nicht das gesamte Internet. Eine Website kann in Moskau und Helsinki funktionieren und gleichzeitig in einem anderen Land, bei einem anderen ISP oder an einem anderen CDN-Edge Probleme haben. Für mich ist der Remote-Check ein zusätzlicher Datenpunkt, kein globales Urteil.
Was Gitae heute prüft
Die aktuelle Version bündelt die Werkzeuge, die ich bei der Eingrenzung eines Ausfalls typischerweise brauche:
- Website check — prüft, ob eine URL von einem externen Server antwortet.
- SSL check — prüft den Status des HTTPS/TLS-Zertifikats und zertifikatsbezogene Probleme.
- DNS check, nslookup und dig — zeigen, wie eine Domain aufgelöst wird und welche DNS-Records zurückkommen.
- Reverse DNS und IP check — zeigen IP- und PTR/reverse-DNS-Daten.
- Domain info und domain age — liefern grundlegende Domain-Metadaten.
- Port check — testet, ob ein Zielport vom jeweiligen Prüfstandort erreichbar ist.
- Find your IP — zeigt die öffentliche IP, die der Dienst sieht.
- Ping und traceroute — liefern Netzwerksignale zu Latenz, Paketverlust und Pfad.
- Hosting check und CMS detection — zeigen Infrastruktur- und Technologiehinweise.
Ich behandle diese Ergebnisse bewusst als Signale. Ein PTR-Record beweist nicht, wem ein Server gehört. CMS-Erkennung anhand öffentlicher Fingerprints beweist keinen exakten Software-Stack. Ein Port, der von einem Prüfpunkt nicht erreichbar ist, kann gefiltert statt überall geschlossen sein.
Wie ich die Ergebnisse lese
Der eigentliche Nutzen entsteht, wenn mehrere Checks gemeinsam betrachtet werden.
Wenn DNS die erwartete Adresse liefert, das HTTPS-Zertifikat gültig ist und die Website von beiden VDS-Standorten antwortet, lokal aber weiterhin nicht lädt, würde ich zuerst den lokalen Netzwerkpfad genauer untersuchen, bevor ich den Server ändere. Wenn DNS inkonsistent ist oder auch der Remote-Check fehlschlägt, spricht mehr dafür, die Infrastruktur zu untersuchen.
Auch Ping und traceroute brauchen Zurückhaltung. ICMP kann gefiltert oder rate-limitiert werden. Ein fehlender Hop bedeutet nicht automatisch, dass dieser Router kaputt ist. Ein Host kann Ping ignorieren und HTTPS trotzdem normal ausliefern. Diese Tools liefern Kontext, keinen endgültigen Pass/Fail-Test.
Der wichtigste Grundsatz ist deshalb: Ein erfolgreicher Einzeltest beweist nicht, dass das ganze System gesund ist, und ein fehlgeschlagener Einzeltest erklärt die Ursache nicht.
Verfügbarkeit und SEO sauber trennen
Auch für SEO ist Verfügbarkeit relevant, aber technische Ausfälle und Ranking-Probleme sind nicht dasselbe. Crawling ist nicht Indexing, und Indexing ist nicht Traffic.
Wenn ein Crawler die Website wegen DNS-, Netzwerk- oder Serverfehlern nicht erreicht, kann er den betroffenen Inhalt in diesem Moment nicht erfolgreich abrufen. Google dokumentiert, dass Netzwerk- und DNS-Fehler beim Crawling ähnlich wie serverseitige 5xx-Fehler behandelt werden und längere Nichterreichbarkeit Crawling und bereits indexierte URLs beeinflussen kann. Daraus folgt aber nicht, dass jeder kurze Ausfall automatisch SEO-Verluste verursacht. Ein Diagnosetool kann ebenso wenig beweisen, dass eine spätere Traffic-Änderung genau durch diesen Ausfall verursacht wurde.
Für Nutzer ist es einfacher: Wenn sie die Website nicht erreichen, können sie sie nicht nutzen. Je nach Projekt kann das Sessions, Leads, Conversions oder Umsatz kosten. Die technische Diagnose misst diesen wirtschaftlichen Schaden jedoch nicht.
Eine praktische Reihenfolge für die Fehlersuche
- Symptom aus einem anderen Netzwerk bestätigen. Nicht davon ausgehen, dass der eigene Browser das gesamte Internet repräsentiert.
- DNS prüfen. Auflösung und erwartete Records kontrollieren.
- HTTPS/TLS prüfen. Zertifikatsstatus und Verbindungsfehler untersuchen.
- Benötigten Port prüfen. Erreichbarkeit vom Prüfstandort testen.
- Netzwerksignale vergleichen. Ping und traceroute als Zusatzinformationen verwenden.
- IP-, reverse-DNS-, Hosting- und CMS-Signale ansehen. Sie helfen zu prüfen, ob man überhaupt die erwartete Infrastruktur erreicht.
- Erst dann die Fehlersuche eingrenzen. Entscheiden, ob die stärksten Hinweise auf Anwendung, Server, DNS, Netzwerkpfad oder lokale Umgebung zeigen.
Das ist kein universelles Incident-Response-Protokoll. Es ist für mich vor allem ein Weg, nicht die falsche Schicht zu ändern, nur weil die einzige Information am Anfang „die Website öffnet nicht“ lautet.
Erst echter Nutzen, später Monetarisierung
Gitae ist derzeit nicht monetarisiert. Ich habe es zuerst für mich selbst gebaut, weil ich eine schnelle Möglichkeit wollte, eine Website von außerhalb meines eigenen Rechners zu prüfen und anschließend direkt zu DNS-, Zertifikats-, Port- und Netzwerkdiagnose überzugehen.
Mein aktuelles Ziel ist, die Diagnose nützlicher zu machen und zu sehen, ob das Projekt über SEO und reale Nachfrage organischen Traffic aufbauen kann. Wenn es auch nur moderaten Traffic erreicht, möchte ich automatisches Website-Monitoring mit sofortigen Messenger-Benachrichtigungen ergänzen. Das würde dieselbe Idee von manueller Diagnose auf Erkennung erweitern: Ausfall bemerken und dem Betreiber schnell genug Informationen geben, um mit der Untersuchung zu beginnen.
Der Kern bleibt absichtlich einfach
„Up“ und „down“ sind Symptome, keine Erklärungen.
DNS, HTTPS/TLS, Routing, Ports, Hosting, Anwendung und das lokale Netz des Nutzers können alle zu demselben sichtbaren Problem führen. Gitae identifiziert nicht magisch jede Root Cause, und die externen VDS-Standorte zeigen nicht, was das gesamte Internet sieht. Sie liefern aber mehrere unabhängige Hinweise an einem Ort.
Genau das wollte ich: ein Werkzeug, das mich von „die Website öffnet nicht“ zur wesentlich nützlicheren Frage bringt: „Welche Schicht sollte ich als Nächstes untersuchen?“