HTTPS
Website- en API-monitoring
Een pagina of een endpoint, opgehaald vanuit vier continenten.
Probeer het nu
Eén check, vanaf één plek, direct, en niets wordt opgeslagen. Een monitor checkt vanaf elke locatie waar we draaien en bevestigt een fout vanaf twee andere continenten voordat iemand wordt gewekt, wat één blik je niet kan laten zien.
Waar het voor is
De check waarmee iedereen begint, en waar de meeste producten stoppen. We vragen de URL op, volgen of weigeren redirects zoals je aangeeft, en lezen de statuscode.
Een statuscode op zichzelf is een zwakke belofte. Een site kan 200 teruggeven terwijl het een foutpagina, een inlogscherm, een gecachte kopie van afgelopen dinsdag, of een lege shell die niet kon renderen serveert. Daarom kan de check ook vereisen dat een bepaalde zin aanwezig is, een redirect ergens specifiek uitkomt, een JSON-veld een bepaalde waarde bevat, en een respons binnen een door jou ingestelde tijd arriveert. Dat zijn de fouten die een statuscode niet kan zien.
Zoals elke check hier draait het vanaf Amsterdam, New York, Sydney and Singapore, en een fout wordt bevestigd vanaf twee andere continenten voordat iemand wordt gewekt. Hoe dat werkt.
Wat je kunt instellen
Alles hieronder staat op het formulier wanneer je er een toevoegt, bij elk abonnement.
- Methode
- GET, HEAD, POST, PUT, PATCH of DELETE. HEAD is de beleefde standaard voor een pagina waarvan je alleen hoeft te weten dat die bestaat.
- Verwachte status
- Welke codes als gezond tellen. Een 401 is correct voor een endpoint dat je moet weigeren, en dat aangeven voorkomt dat we je werkende authenticatie als een storing rapporteren.
- Trefwoord
- Een zin die aanwezig moet zijn, of juist afwezig. De goedkoopste manier om een 200 te vangen die eigenlijk een foutpagina is.
- JSON-asserties
- Een pad en de waarde die het moet bevatten, voor een API die 200 teruggeeft met een body die iets anders zegt.
- Redirects
- Volg de keten, of behandel een redirect als het antwoord. Met een verwachte locatie vangt dit een site die stilletjes ergens heen wordt geleid waar dat niet hoort.
- Traag is een fout
- Een responstijd waarboven de check als gedegradeerd telt in plaats van up, en hoeveel achter elkaar voordat we dat zeggen.
- Authenticatie
- Basic of Bearer. Versleuteld opgeslagen, ontsleuteld door het control plane, en aan de probe gegeven met de opdracht in plaats van een gehuurde machine de sleutel tot alles te geven.
- Headers en body
- Alles wat de request nodig heeft. Eén header per regel, en een body voor de methoden die er een gebruiken.
- Timeout
- Hoe lang je wacht voordat je het een failure noemt.
- Bevestigingen
- Hoeveel andere continenten moeten het eens zijn voordat iemand wordt gewekt. Nul is mogelijk, maar meestal niet wat je wilt.
Vragen
Wat betekent een 502 of een 503, en krijg je er een alert op?
Een 502 is de server ervoor die zegt dat de server erachter een antwoord gaf dat niet bruikbaar was, en een 503 is een server die aangeeft geen requests aan te nemen, wat de meeste frameworks teruggeven tijdens een restart. Beide laten de check standaard falen, omdat de standaard 2xx en 3xx verwacht. Als een code correct is voor dat endpoint, zet je die in de lijst van verwachte statuscodes en dan telt het niet meer als een outage.
Controleer je de SSL/TLS-certificaatketen?
Ja. De check maakt verbinding zoals een browser dat doet, tegen de public trust store, dus een ontbrekende intermediate, een self-signed certificaat, een hostname mismatch of een verlopen certificaat laat de check falen met een TLS error in plaats van een statuscode. Wat het niet doet, is de resterende dagen tellen, dat is de taak van de SSL/TLS-certificaatmonitor. Verificatie kan per monitor worden uitgeschakeld voor een interne host die je kent.
Kan ik een API endpoint monitoren in plaats van een pagina?
Daar zijn de requestopties voor, en daarom is er geen aparte API-monitortype die hiervan afwijkt. Kies POST, PUT, PATCH of DELETE, voeg headers en een body toe, authenticeer met basic of bearer credentials, accepteer welke statuscodes correct zijn, en controleer op een pad in de JSON die terugkomt.
Wat is het verschil tussen een timeout en een trage response?
Een timeout is een check die geen antwoord kreeg binnen de toegestane seconden, en wordt gerapporteerd als een failure zonder statuscode, behalve bij een verbinding die direct werd geweigerd. Slow is een antwoord dat wel aankwam maar te lang duurde: stel een response time in waarboven de check als degraded telt, en hoeveel achter elkaar voordat iemand erover wordt geïnformeerd.
Volg je redirects?
Niet tenzij je dat aangeeft, wat vaak genoeg mensen verrast om het uit te leggen. Een site die 302 naar een parkeerpagina begint te antwoorden is kapot, en een checker die dat stil volgt en een 200 vindt zou dat als gezond rapporteren. Zet volgen aan wanneer de redirect het doel is, en geef de locatie op waar je verwacht te eindigen.
Voert de check JavaScript uit of rendert het de pagina?
Nee, en we zeggen dat liever dan iets anders impliceren. Het haalt het document op dat de server stuurt en leest dat, dus een keyword check moet iets in de HTML matchen in plaats van iets dat een framework later schildert. Voor een pagina die in de browser wordt gerenderd, controleer je op de statuscode, de response time en een zin die echt in de response staat.
Is de response time wat mijn bezoekers ervaren?
Het is de tijd die onze probe wachtte, van request tot response, op een verbinding zonder cold cache en zonder browser ervoor. Dat maakt het een uitstekende tripwire voor een server die langzamer wordt en een slechte weergave van één persoon op een telefoon. Real user monitoring en Core Web Vitals beantwoorden de andere vraag en deze check doet niet alsof.
Waarom niet gewoon curlen vanuit een cron job?
Voor één URL vanaf één machine is een cron job echt bijna alles hiervan, en iedereen die iets anders zegt verkoopt je iets. Wat het je niet geeft, is een plek om te draaien die zelf niet stil kan uitvallen: een check op een box die zijn netwerk kwijt is rapporteert niets, wat precies lijkt op alles dat in orde is. Het vertelt je ook niet of een verbroken link tussen jou en de site komt door de site zelf, wat opnieuw checken vanaf twee andere continenten oplost, en het laat je nog steeds zelf het deel bouwen dat iemand wakker maakt.
Hoe verschilt dit van een browser-gebaseerde synthetische check?
Een synthetische check gebruikt een echte browser, dus die ziet dingen die wij niet kunnen zien: een pagina die leeg blijft omdat een script faalde, een knop die niet meer werkt, een lettertype dat nooit geladen wordt. Deze check doet alleen de aanvraag en leest het antwoord, wat betekent dat hij niets van dat alles kan zien. Wat je in plaats daarvan krijgt, is een check die goedkoop genoeg is om elke dertig seconden te draaien vanuit drie continenten, op elke URL die je hebt, in plaats van een paar journeys een paar keer per uur. Ze beantwoorden verschillende vragen en veel mensen willen beide.