Ik bouwde Gitae omdat ik steeds tegen dezelfde praktische vraag aanliep: is de website echt down, of ligt het probleem alleen aan mijn kant?
Eén browsertab is een zwak diagnostisch instrument. Een pagina kan niet laden omdat de origin-server uitgevallen is, maar ook door DNS, een probleem met het HTTPS-certificaat, routing, een firewallregel, een gesloten of gefilterde poort, de ISP, een VPN-route, browserstatus of lokale cache. Het zichtbare symptoom is hetzelfde. De juiste actie is dat niet.
Dat wilde ik met Gitae oplossen: niet alleen een groen of rood lampje tonen, maar het probleem terugbrengen tot de laag die ik vervolgens moet onderzoeken.
Het echte probleem achter ‘de site is down’
Veel eenvoudige website-checkers beantwoorden één smalle vraag: reageerde deze URL vanaf één locatie op één moment? Dat is nuttig, maar het is nog geen diagnose van een storing.
Als DNS fout staat, helpt een app herstarten niet. Als HTTPS faalt door het certificaat, is de pagina-inhoud niet relevant. Als een TCP-poort niet bereikbaar is, kan de server zelf nog prima draaien. En als de site vanaf een externe server wel opent maar via mijn eigen verbinding niet, kan het probleem ergens op het pad tussen mijn netwerk en de bestemming zitten in plaats van op de application server.
Daarom bouwde ik Gitae rond een nuttiger model: een website is een keten van afhankelijkheden en elke check levert bewijs over slechts één deel van die keten.
Een extern gezichtspunt, geen absolute waarheid
De checks van Gitae draaien vanaf mijn eigen VDS-servers in Moskou en Helsinki. Daardoor krijg ik meetpunten buiten de computer en het netwerk waarop ik het probleem voor het eerst zag.
Als de site lokaal faalt maar vanaf beide VDS-locaties reageert, is dat nuttige informatie: de origin is in elk geval niet overal onbereikbaar. Dan kijk ik eerder naar lokale DNS, ISP-routing, VPN, browserstatus, firewall of een ander padgebonden probleem. Faalt de site ook vanaf de externe probes, dan is er meer reden om server, DNS, certificaat, routing of een breder netwerkprobleem te onderzoeken.
Een remote check is echter niet automatisch ‘betrouwbaarder’ dan een lokale check. Twee VDS-locaties vertegenwoordigen niet het hele internet. Een site kan vanuit Moskou en Helsinki werken en vanuit een ander land, een andere ISP, een andere CDN-edge of een ander netwerk toch falen. Ik zie het externe resultaat als een extra observatiepunt, niet als een wereldwijd oordeel.
Wat Gitae vandaag controleert
- Website check — controleert of een URL vanaf een externe server reageert.
- SSL check — inspecteert de status van het HTTPS/TLS-certificaat en certificaatgerelateerde problemen.
- DNS check, nslookup en dig — helpen zien hoe een domein resolveert en welke DNS-records worden teruggegeven.
- Reverse DNS en IP check — tonen IP-informatie en PTR/reverse-DNS-data.
- Domain info en domain age — geven basale domeinmetadata.
- Port check — test of een doelpoort vanaf de probe-locatie bereikbaar is.
- Find your IP — toont het publieke IP-adres dat de dienst ziet.
- Ping en traceroute — leveren netwerksignalen over latency, packet loss en het pad naar een host.
- Hosting check en CMS detection — tonen infrastructuur- en technologiesignalen die bij identificatie kunnen helpen.
Ik behandel die resultaten bewust als signalen. Een PTR-record bewijst niet wie een server bezit. CMS-detectie op basis van publieke fingerprints bewijst niet de exacte softwarestack. En een poort die vanaf één probe onbereikbaar is, kan onderweg worden gefilterd in plaats van overal gesloten te zijn.
Hoe ik de resultaten interpreteer
De waarde ontstaat door meerdere checks samen te bekijken.
Als DNS het verwachte adres teruggeeft, het HTTPS-certificaat geldig is en de website vanaf beide VDS-locaties reageert, maar ik hem lokaal nog steeds niet kan openen, onderzoek ik eerst het lokale netwerkpad voordat ik de server aanpas. Als DNS inconsistent is of de remote website check ook faalt, is er meer aanleiding om de infrastructuur te bekijken.
Ook ping en traceroute vragen om terughoudendheid. ICMP kan worden gefilterd of rate-limited. Een ontbrekende hop betekent niet automatisch dat die router kapot is, en een host die niet op ping reageert kan HTTPS nog steeds normaal aanbieden. Deze tools voegen context toe; ze geven geen definitief oordeel.
Mijn belangrijkste regel is daarom: één geslaagde check bewijst niet dat het hele systeem gezond is, en één mislukte check verklaart de oorzaak niet.
Beschikbaarheid en SEO zijn niet hetzelfde
Beschikbaarheid is ook voor SEO relevant, maar een technische storing is niet hetzelfde als een rankingprobleem. Crawling is niet indexing en indexing is niet traffic.
Als een crawler de site niet kan bereiken door DNS-, netwerk- of serverfouten, kan hij de betreffende content op dat moment niet succesvol ophalen. Google documenteert dat netwerk- en DNS-fouten tijdens crawling vergelijkbaar worden behandeld met server-side 5xx-fouten en dat langdurige onbereikbaarheid crawling en reeds geïndexeerde URL’s kan beïnvloeden. Dat betekent niet dat elke korte storing automatisch SEO-verlies veroorzaakt. Een diagnostische tool kan ook niet bewijzen dat een latere verandering in traffic door precies die storing is veroorzaakt.
Voor gebruikers is het eenvoudiger: als zij de site niet kunnen bereiken, kunnen zij hem niet gebruiken. Afhankelijk van het project kan dat gemiste sessies, leads, conversies of omzet betekenen. De technische check berekent die zakelijke impact echter niet.
Een praktische volgorde voor een ‘down’ website
- Bevestig het symptoom vanaf een ander netwerk. Neem niet aan dat de lokale browser het hele internet vertegenwoordigt.
- Controleer DNS. Bevestig resolutie en verwachte records.
- Controleer HTTPS/TLS. Kijk naar certificaatstatus en verbindingsfouten.
- Controleer de benodigde poort. Test bereikbaarheid vanaf de probe.
- Vergelijk netwerksignalen. Gebruik ping en traceroute als ondersteuning.
- Bekijk IP, reverse DNS, hosting en CMS. Die signalen kunnen helpen bevestigen dat je de verwachte infrastructuur bereikt.
- Verklein daarna pas het onderzoek. Bepaal of het bewijs sterker wijst naar applicatie, server, DNS, netwerkpad of lokale omgeving.
Dit is geen universeel incident-responseprotocol. Het is vooral een manier om de fout te vermijden die ik wilde oplossen: aan de verkeerde laag sleutelen omdat de enige informatie luidt ‘de site opent niet’.
Eerst echte bruikbaarheid, daarna monetisatie
Gitae is op dit moment niet gemonetiseerd. Ik bouwde het eerst voor mezelf omdat ik een snelle manier wilde om een site buiten mijn eigen machine te controleren en daarna direct door te gaan naar DNS-, certificaat-, poort- en netwerkdiagnose.
Mijn huidige doel is de diagnose nuttiger maken en kijken of het project via SEO en echte vraag organisch verkeer kan krijgen. Als het zelfs maar bescheiden traffic bereikt, wil ik automatische website-monitoring met directe messenger-alerts toevoegen. Dat is dezelfde gedachte uitgebreid van handmatige diagnose naar detectie: merken dat iets onbereikbaar wordt en de eigenaar meteen genoeg informatie geven om het onderzoek te starten.
De kern blijft bewust eenvoudig
‘Up’ en ‘down’ zijn symptomen, geen verklaringen.
DNS, HTTPS/TLS, routing, poorten, hosting, de applicatie en het netwerk van de gebruiker kunnen allemaal hetzelfde ogenschijnlijk simpele beschikbaarheidsprobleem veroorzaken. Gitae vindt niet magisch elke root cause en die externe VDS-locaties laten niet zien wat het hele internet ziet. De tool kan wel meerdere onafhankelijke signalen op één plek verzamelen.
Dat is wat ik zelf wilde: van ‘de site opent niet’ naar de veel nuttigere vraag ‘welke laag moet ik nu onderzoeken?’