API-monitoring tool voor endpointvalidatie & tekstanalyse
Met de API-monitoring tool van HostTracker stel je beleidsregels in voor de content die van je endpoints wordt opgehaald. Bij elke check wordt eerst gecontroleerd of het content type geldig is. Daarna wordt de content doorzocht op specifieke waarden.
Meer dan uptime valideren - controleer of je API's ook echt werken
HostTracker controleert je API-endpoints volgens een schema, waarbij de statuscode, het content type en de waarden in de respons worden gevalideerd - niet alleen of de server antwoordt.
Waarom API-monitoring belangrijk is
Het monitoren van je API's is echt belangrijk. Het helpt je in de gaten te houden hoe goed ze presteren, hoe beschikbaar ze zijn, en of ze doen wat ze horen te doen. Het zorgt er ook voor dat ze aan prestatienormen voldoen, wat helpt om potentiële problemen te voorkomen
Uptime + prestaties in één check
Uptimemonitoring komt er in de kern op neer dat een API-endpoint op vaste intervallen wordt gecontroleerd om te zorgen dat het er is wanneer je het nodig hebt en goed werkt. Prestatiemonitoring gaat over meten hoe snel en betrouwbaar een API op requests reageert.
Zakelijke impact van betrouwbare API's
Hoe goed API's werken, kan grote invloed hebben op hoe gebruikers apps ervaren, hoe goed alles in zijn geheel functioneert, en zelfs op de omzet van het bedrijf.
Wat een API-monitor bij elke run controleert
REST-API-monitoring lijkt oppervlakkig op uptime-monitoring, maar is een andere taak. Een API wordt door code gebruikt, niet door mensen, en code is onvergevingsgezind op manieren waarop een browser dat niet is. Een menselijke bezoeker tolereert een pagina die net iets verkeerd wordt weergegeven; een integratie die een veld van het verkeerde type ontvangt, gaat gewoon stuk. API-monitoring moet daarom meer lagen controleren dan alleen "heeft de server geantwoord", en HostTracker controleert ze in volgorde, en faalt bij de eerste laag die niet standhoudt.
| Laag | Wat wordt gecontroleerd | De storing die het opvangt |
|---|---|---|
| 1 · Bereikbaarheid | DNS wordt herleid, de TCP-verbinding gaat open, de TLS-handshake wordt voltooid | Het endpoint is verdwenen, het certificaat is verlopen, de host is vanuit een deel van de wereld niet routeerbaar |
| 2 · Status | De HTTP-statuscode, getoetst aan de codes die je accepteert of expliciet als fout behandelt | Een 500 na een release, een 401 door een verlopen inloggegeven, een onverwachte 429 |
| 3 · Timing | Totale reactietijd, en de opsplitsing over verbinding, TLS, headers en body | Een endpoint dat nog werkt maar stilletjes van 200 ms naar vier seconden is gegaan |
| 4 · Vorm | Content type en headers - is dit daadwerkelijk JSON, of een HTML-foutpagina die zich als 200 voordoet | Een foutpagina of een login-doorverwijzing geserveerd waar een payload zou moeten staan. De klassieke stille API-storing |
| 5 · Inhoud | Een waarde die uit de payload wordt geselecteerd, of vrije assertions over de hele respons | Een veld dat ontbreekt na een schemawijziging, een lege resultatenset, een versienummer dat is teruggedraaid, een foutveld dat verschijnt in een succesvolle respons |
Lagen één tot en met drie zijn wat een gewone uptime-check je geeft. Vier en vijf zijn wat er API-monitoring van maakt - en dat zijn de lagen waar de meeste echte API-incidenten zich daadwerkelijk afspelen.
De request configureren
Voordat er iets gevalideerd kan worden, moet de monitor de request doen die je API verwacht. Het volledige requestoppervlak is beschikbaar op een API-monitor:
| Instelling | Wat je ermee kunt doen |
|---|---|
| HTTP-methode | GET, HEAD, POST, PUT, PATCH of DELETE |
| Aangepaste headers | Elke naam-waardecombinatie die je nodig hebt - een bearer-token, een API-sleutel, een tenant-ID, een Accept-versieheader. Headers worden bij een doorverwijzing alleen naar dezelfde host doorgestuurd, zodat een inloggegeven nooit lekt naar een derde partij waar je endpoint naartoe verwijst. |
| Requestbody | Een ruwe body voor POST, PUT en PATCH, of form-encoded parameters |
| HTTP-authenticatie | Een gebruikersnaam en wachtwoord, met het schema dat de server vraagt onderhandeld op de verbinding |
| Doorverwijzingen | Volgen of niet, een maximum instellen voor hoeveel er worden gevolgd, of elke doorverwijzing als storing behandelen - handig voor een endpoint dat rechtstreeks moet antwoorden |
| Time-out | Tot 100 seconden, standaard 40 - en een time-out is een mislukte check, precies wat je wilt bij een endpoint met een SLA |
| Maximale responsgrootte | Standaard 1 MB, aan te passen naar boven, zodat een uit de hand gelopen respons de check niet kan opslokken |
| Geaccepteerde en afgewezen statuscodes | Lijsten met codes om te negeren, en codes om als fout te behandelen - het middel voor een endpoint dat legitiem met 401 of 404 antwoordt als onderdeel van zijn contract |
| DNS-controle | Herleiden via specifieke resolvers, de DNS-cache van het checkpoint omzeilen, en toetsen naar welke IP-adressen de host wordt herleid |
| TLS-strengheid | Optioneel een geldige certificaatketen, TLS 1.2 of hoger, ciphers boven 128-bit en een intrekkingscontrole vereisen - plus bewaking van het certificaatverval op dezelfde verbinding |
Assertions: beschrijven hoe een gezonde respons eruitziet
De meest expressieve manier om een respons te valideren, is er regels voor te schrijven. Elke regel is één regel code, regels worden met AND gecombineerd, en een monitor kan er tot twintig dragen. Dit is de geverifieerde startbundel voor een JSON-API:
status isOk
header("Content-Type") contains "json"
body.json.path("$.count") gt 0
time lt 5s
Vier regels, en samen dekken ze de vier lagen die ertoe doen: het endpoint antwoordde met een 2xx,
het antwoordde met JSON in plaats van een foutpagina, de payload bevat een echt resultaat in plaats
van een leeg resultaat, en dat gebeurde allemaal binnen het tijdsbudget. Los ook nuttige regels uit
dezelfde catalogus zijn onder andere body.json.path("$.status") eq "ok" voor het eigen
gezondheidsoordeel van een API, body.json.path("$.error") absent voor een foutveld dat
verschijnt in een verder succesvolle respons, body.json.path("$.version") eq "2.4.1" om
een onbedoelde terugdraaiing op te vangen, redirects.count eq 0 voor een endpoint dat
rechtstreeks moet antwoorden, en cert.days.left gt 14 voor het certificaat op dezelfde
verbinding.
Waar een regel over kan gaan
Regels lezen onderwerpen uit de respons en vergelijken ze. De onderwerpen omvatten de statuscode; de
totale reactietijd en de onderdelen daarvan voor verbinding, TLS, DNS, headers en body; de ruwe body
samen met de grootte en een hash ervan; gestructureerde queries in de payload als JSON, XML, HTML of
YAML; individuele responseheaders; de uiteindelijke en oorspronkelijke URL en hun onderdelen; de
doorverwijzingsketen, stap voor stap; het aantal resterende dagen, de uitgever en de namen van het
certificaat; het afgesproken TLS-protocol en de cipher; de adressen die DNS teruggaf; en
Set-Cookie. Vergelijkingen lopen van de voor de hand liggende - gelijk aan, kleiner dan,
groter dan - tot contains, startsWith, endsWith,
matches voor een reguliere expressie, containsAny en containsAll
voor een verzameling, in voor een lijst met toegestane waarden, en exists,
isNumber en unique.
Er is ook een as voor wijzigingsdetectie: een regel kan de waarde van deze run vergelijken met die van de vorige run, zodat je kunt toetsen dat een teller nooit terugloopt of dat een body-hash niet is veranderd - het type regel dat een stille terugdraaiing of een ongeautoriseerde inhoudswijziging opvangt in plaats van een storing.
Eén waarde uit de payload halen
Naast de regeltaal is er een eenvoudiger pad voor één waarde, dat al lang deel uitmaakt van de API-monitoring hier en vaak alles is wat een check nodig heeft. Je vertelt de monitor hoe de body geparsed moet worden, hoe daaruit één waarde geselecteerd wordt, en wat die waarde moet zijn:
- Parsen als JSON, en de selector is een JSONPath-expressie.
- Parsen als XML, en de selector is een XPath-expressie - wat SOAP en andere XML-diensten eenvoudig controleerbaar maakt.
- Behandelen als platte tekst, en de selector is een meerregelige, niet-hoofdlettergevoelige reguliere expressie.
Het predicaat dat op de geselecteerde waarde wordt toegepast, omvat gelijk aan en ongelijk aan, kleiner dan en groter dan in zowel strikte als inclusieve vorm, lidmaatschap van een lijst met toegestane waarden of uitsluiting daarvan, binnen of buiten een numeriek bereik, en een test of de waarde null is of volledig ontbreekt.
Een onjuiste selector wordt geweigerd bij het opslaan, niet om drie uur 's nachts. De selector wordt gecompileerd op het moment van validatie, dus een typefout in een JSONPath of een XPath is een fout op het formulier, in plaats van een monitor die al sinds het aanmaken stilletjes faalt - of stilletjes slaagt.
De storingen die een statuscode-check niet kan zien
Elke storing in deze tabel geeft HTTP 200 terug. Dat is precies het probleem met een API alleen op zijn statuscode monitoren: het transport is geslaagd, dus rapporteert het transport succes.
| Wat er misging | Hoe de respons eruitziet | Wat het opvangt |
|---|---|---|
| Er wordt een foutpagina geserveerd waar een payload zou moeten staan | 200, met HTML | Een content-type-assertion, of een regel dat de body als JSON parseert |
| De zoekindex is gestopt met herbouwen | 200, met een lege resultatenarray | Een regel dat het aantal resultaten minstens één is |
| Een veld is hernoemd bij een schemawijziging | 200, geldige JSON, ontbrekend veld | Een regel dat het veld bestaat |
| Een release is teruggedraaid zonder dat iemand het merkte | 200, ouder versienummer | Een regel die het versieveld vastpint |
| Er verschijnt een foutveld binnen een succesvolle envelop | 200, met een ingesteld foutveld | Een regel dat het foutveld afwezig is |
| Een downstream-afhankelijkheid faalt en de API degradeert netjes | 200, met gedeeltelijke of verouderde data | Een regel op het eigen gezondheidsveld van de API, of een versheidswaarde in de payload |
| Het endpoint antwoordt nu in vier seconden in plaats van tweehonderd milliseconden | 200, uiteindelijk | Een reactietijdregel |
| Authenticatie werd stilletjes niet meer toegepast | 200, met data die het niet zou moeten teruggeven | Een aparte negatieve monitor - een niet-geauthenticeerd verzoek dat 401 moet teruggeven |
Die laatste rij is het bewust doen waard. Een tweede monitor die geen inloggegevens meestuurt en toetst op een 401 is de goedkoopste manier om erachter te komen dat een autorisatielaag per ongeluk is uitgeschakeld - een storing die geen enkele hoeveelheid positieve tests ooit aan het licht zal brengen.
Controleren vanaf 300+ locaties, zonder vals alarm
API-monitors draaien vanaf de publieke checkpointvloot van HostTracker - 300+ checkpoints in 158 steden - en je kiest welke locaties een bepaalde monitor gebruikt. Geografie doet er bij een API meer toe dan bij een website: een endpoint achter een CDN of een geo-gerouteerde load balancer kan gezond zijn in Frankfurt en falen in São Paulo, en een check vanaf één locatie kan dat onmogelijk zien. Hetzelfde geldt voor DNS - een verouderd of verkeerd geconfigureerd record verspreidt zich vaak ongelijkmatig, wat er van binnenuit uitziet als een sporadische storing en van buitenaf als een regionale.
Vanaf veel plekken draaien brengt een voor de hand liggend risico met zich mee: meer checkpoints, meer kansen dat één instabiel netwerkpad vals alarm slaat. HostTracker regelt dat met een bevestigingsquorum. Wanneer een checkpoint een storing meldt, wordt de check herhaald vanaf extra onafhankelijke checkpoints, en de statusverandering wordt pas bevestigd zodra ze het eens zijn - standaard een meerderheidsoordeel over maximaal zeven agents, met een minimum van drie. Je kunt dit strenger maken, door een vast aantal agents te vereisen dat de storing meldt, of volledige overeenstemming tussen hen, voor een endpoint waar een vals alarm erger is dan een trage melding.
Na bevestiging volgt de melding de vertraging die elk contact heeft gekozen - direct, of na 3, 5, 15, 30 of 60 minuten, of na 3, 6, 12 of 24 uur ononderbroken storing - via de negen notificatiekanalen: e-mail, sms, spraakoproep, webhook, Slack, webpush en de berichten-apps Telegram, Discord en Viber. Het webhookkanaal is hoe meldingen een incidentmanager of een teamchattool bereiken.
REST, GraphQL, SOAP en webhookontvangers
De check is een configureerbaar HTTP-verzoek plus responsanalyse, dus wat erbij past volgt daar direct uit.
- REST- en JSON-API's zijn het alledaagse geval, en REST-API-monitoring is wat de meeste accounts als eerste inrichten: een GET of POST, headers voor het inloggegeven, en JSONPath- of assertion-regels over de payload.
- GraphQL werkt als een POST met de query in de body, gevolgd door JSONPath in
data- en het is de moeite waard om te toetsen dat heterrors-veld afwezig is, aangezien GraphQL berucht is om het antwoorden met 200 terwijl er fouten in zitten. - SOAP- en XML-diensten zijn een POST met de envelope als body en XPath als selector, wat precies zo in de respons grijpt als de specificatie bedoelt.
- Webhookontvangers en callback-endpoints kunnen worden gecontroleerd op bereikbaarheid en op de respons die ze geven op een correct gevormd verzoek - waardevol, omdat een ontvanger die stilletjes is gestopt met het accepteren van leveringen nergens in je eigen systeem een fout veroorzaakt.
- Health- en readiness-endpoints zijn, als je ze hebt, het waardevolste doelwit van allemaal: je applicatie weet al of haar afhankelijkheden gezond zijn, en een assertion op dat oordeel maakt van die eigen kennis een melding.
Wat er niet bij past, is een reeks - een token verkrijgen, het gebruiken, en dan de resource verwijderen. Een API-monitor doet één verzoek per run. Voor een echte meerstaps-reis is de browsergestuurde transactiecheck het juiste middel; voor de laadtijd van een pagina in plaats van een endpoint, zie browsertoegang en paginalaadtijd.
Je eerste API-monitor instellen
- Probeer het endpoint eerst met de gratis directe HTTP-check - geen login vereist - zodat je de status, timing en respons ziet waar je zo meteen regels tegen gaat schrijven.
- Voeg een monitor toe en kies het type API-monitoring. Stel de methode in en voeg de headers of body toe die het endpoint nodig heeft; geef de monitor een eigen inloggegeven in plaats van dat van een persoon te hergebruiken.
- Schrijf de assertions. Begin met de bundel van vier regels hierboven - status, content type, één betekenisvolle waarde uit de payload, en een reactietijdbudget - wat een oprecht goede standaard is voor bijna elke JSON-API.
- Kies een interval tussen één minuut en 24 uur. Drie minuten is de standaard en een redelijk startpunt; reserveer één minuut voor de endpoints waarvan een storing een incident is.
- Kies de locaties. Twee of drie regio's waar je afnemers daadwerkelijk zitten, verslaan één enkele locatie, en dat is wat een regionale storing zichtbaar maakt.
- Voeg de contacten toe en stel voor elk de meldingsvertraging in. Niet iedereen hoeft het al bij minuut één te horen.
- Laat het een dag draaien, en bekijk dan de geschiedenis van de reactietijd voordat je de timingregel aanscherpt. Een budget dat op echte data is gebaseerd, houdt stand; een budget dat op een gok is gebaseerd, wordt gedempt.
API-monitoring versus APM en observability
Deze vullen elkaar aan en worden vaak met elkaar verward. Een observability- of APM-platform instrumenteert je code en vertelt je wat er binnen een verzoek is gebeurd. Externe API-monitoring staat buiten je infrastructuur en vertelt je wat een afnemer daadwerkelijk ontvangt. Beide zijn de moeite waard; geen van beide vervangt de ander.
| Externe API-monitoring | APM / observability | |
|---|---|---|
| Uitkijkpunt | Buiten je infrastructuur, over het publieke internet | Binnen je applicatieproces |
| Vereist codewijzigingen | Nee - er wordt nergens iets geïnstalleerd | Een agent of SDK in elke dienst |
| Ziet DNS-, routerings-, TLS- en CDN-problemen | Ja - ze liggen op het pad dat het aflegt | Nee - ze gebeuren voordat het verzoek aankomt |
| Rapporteert nog steeds wanneer het hele platform down is | Ja - het wordt niet door jou gehost | Vaak niet - wat rapporteert, is zelf ook down |
| Verklaart waarom een verzoek traag was binnen je code | Nee - het ziet de tijdsopsplitsing, niet je stack | Ja - dat is precies het doel ervan |
| Dekt een endpoint dat vandaag door niemand is aangeroepen | Ja - het roept het volgens een schema aan | Nee - geen verkeer, geen telemetrie |
Het patroon waar de meeste teams op uitkomen, is externe monitoring voor detectie en interne telemetrie voor diagnose: HostTracker vertelt je dat een endpoint kapot is, vanaf waar, en tegen welke regel, en je eigen tracing vertelt je waarom. Daarnaast verklaart een databasequerymonitor vaak een API die traag is geworden, en verklaart servermonitoring de host waarop deze draait.
Beperkingen die het weten waard zijn
- Eén verzoek per run. Geen tokenuitwisseling, geen geketende aanroepen. Richt de monitor op een endpoint waarvan de authenticatie niet verloopt, en gebruik een transactiecheck wanneer wat je moet bewijzen een reeks is.
- Twintig assertion-regels per monitor. In de praktijk ruim voldoende - de bundel van vier regels dekt de meeste endpoints - maar goed om te weten voordat je een contracttest met honderd regels plant.
- Assertion-modus vervangt de oudere trefwoord- en statusinstellingen. De twee modellen kunnen niet op één monitor worden gecombineerd; kies de regeltaal of de oude trefwoordmodus, niet allebei.
- Geen OpenAPI- of JSON-schemavalidatie. Je toetst op specifieke waarden en structuren, niet op een heel schemadocument.
- De requestbody heeft een lengtelimiet, dus een zeer grote POST-payload is niet waarvoor deze check is gebouwd.
- Het is monitoring, geen testen. Het juiste doelwit is een alleen-lezen of idempotent endpoint. Een monitor die elke drie minuten vanaf meerdere locaties data wijzigt, wordt uiteindelijk de oorzaak van een incident in plaats van wat het detecteert.
Veelgestelde vragen
Een API-monitoring tool stuurt volgens een schema requests naar je API-endpoints en beoordeelt de respons aan de hand van regels die je zelf instelt, in plaats van alleen te bevestigen dat de server reageerde. HostTrackers API-monitoring controleert eerst of het endpoint bereikbaar is en de verwachte HTTP-statuscode teruggeeft, checkt vervolgens of het content type van de respons overeenkomt met wat verwacht wordt (JSON, XML, platte tekst, enzovoort), en doorzoekt tot slot de responsinhoud op specifieke waarden of patronen die je hebt geconfigureerd. Deze gelaagde aanpak vangt problemen op die een simpele "is-het-online"-check volledig zou missen - een endpoint kan een normale 200-statuscode teruggeven terwijl het toch corrupte, onvolledige of verouderde data levert door een bug in de backend, een mislukte databasequery of een kapotte integratie verderop in de keten. Door vooraf duidelijke validatiebeleidsregels in te stellen, weet de monitor precies hoe een gezonde respons voor jouw specifieke API eruitziet.
Website-uptimemonitoring controleert doorgaans alleen of een pagina laadt en een normale HTTP-statuscode teruggeeft, wat prima werkt voor pagina's die bedoeld zijn om in een browser bekeken te worden. API-monitoring gaat verder omdat API's door code worden gebruikt, niet door mensen, waardoor een "werkende" respons aan strengere eisen moet voldoen: het juiste content type, een geldige structuur en correcte waarden in de payload, niet alleen een succesvolle statuscode. Een endpoint kan HTTP 200 teruggeven terwijl de daadwerkelijke data fout, ontbrekend of misvormd is, en traditionele uptimechecks alleen zullen dat niet opmerken omdat ze uitsluitend naar de statuscode kijken. HostTrackers API-monitoring controleert beide lagen - bereikbaarheid en statuscode, zoals uptimemonitoring doet, plus content-type-validatie en het doorzoeken van de responsinhoud op verwachte waarden - wat een veel nauwkeuriger beeld geeft van of een API daadwerkelijk correct functioneert.
Ja, dat is de kern van wat API-monitoring onderscheidt van een basale uptimecheck. Met HostTracker stel je validatiebeleid in dat verder gaat dan bevestigen dat het endpoint reageerde: je geeft het verwachte content type op, zodat een check faalt zodra een endpoint onverwacht HTML in plaats van JSON teruggeeft (een veelvoorkomend symptoom van een foutpagina die wordt geserveerd in plaats van echte data), en je doorzoekt de responsinhoud op specifieke waarden die aanwezig moeten zijn om de respons als gezond te beschouwen. Zo kan een check falen terwijl de HTTP-statuscode er volkomen normaal uitziet, waardoor situaties worden opgevangen waarin een backendbug of een kapotte downstreamintegratie een technisch geslaagde maar functioneel foutieve respons oplevert. Het valideren van de daadwerkelijke inhoud, niet alleen de connectiviteit, is wat API-monitoring zinvol maakt voor endpoints waar andere systemen van afhankelijk zijn.
Nadat is bevestigd dat een endpoint reageert en het content type overeenkomt met je verwachting, doorzoekt HostTrackers API-monitoring de teruggegeven inhoud op de specifieke waarden of tekstpatronen die je als onderdeel van het validatiebeleid van de check hebt geconfigureerd. Zo kun je bevestigen dat een respons een bepaald veld, statuswaarde of stukje data bevat dat aangeeft dat het endpoint correct functioneert - bijvoorbeeld door te controleren dat de respons van een health-check-endpoint een verwachte statuswaarde bevat in plaats van een foutmelding verpakt in een 200-respons. Als de verwachte inhoud niet wordt gevonden, wordt de check als mislukt gemarkeerd, ook al is de verbinding zelf geslaagd, en word je gewaarschuwd via je geconfigureerde notificatiekanalen. Dit soort content-bewuste controle is bijzonder nuttig om gedeeltelijke storingen op te sporen, waarbij een API technisch bereikbaar is maar stilletjes onvolledige of onjuiste data teruggeeft.
De controlefrequentie is instelbaar, en HostTrackers betaalde abonnementen ondersteunen intervallen tot wel eens per minuut voor al zijn monitoringtypen, zodat API-endpoints die cruciaal zijn voor de uptime van je applicatie vrijwel continu gecontroleerd kunnen worden. Het permanent gratis abonnement voert elke 30 minuten checks uit op maximaal twee monitors, wat een redelijke frequentie is voor minder kritieke of interne API's waarbij een korte vertraging in het opsporen van een probleem niet kostbaar is. Voor bedrijfskritische API's - die een live applicatie, een betaalflow of een integratie aandrijven waar je klanten op vertrouwen - betekenen kortere intervallen dat problemen worden opgemerkt en aangepakt voordat ze uitgroeien tot een grotere storing die gebruikers daadwerkelijk merken. Met een gratis proefperiode van 30 dagen met alle functies, checks per minuut en zonder creditcard kun je testen hoe snel de detectie voor jouw specifieke API moet zijn.
Ja. Een API-monitor kan versturen wat het endpoint nodig heeft om het verzoek te accepteren: willekeurige aangepaste headers - zo geef je een bearer-token, een API-sleutelheader of een tenant-ID mee - plus een gebruikersnaam en wachtwoord voor HTTP-authenticatie, een requestbody voor POST, PUT of PATCH, en elke HTTP-methode van GET en HEAD tot POST, PUT, PATCH en DELETE. Het praktische advies is hetzelfde als voor elke geautomatiseerde client: geef de monitor een eigen inloggegeven in plaats van dat van een persoon te hergebruiken, geef het de kleinst mogelijke scope die het endpoint nog zinvol test, en geef de voorkeur aan een alleen-lezen endpoint of een speciale health-route boven iets dat data wijzigt. Als je tokens kortlevend zijn, richt de monitor dan op een endpoint waarvan de authenticatie niet verloopt - een health- of statusroute beveiligd met een langlevende sleutel - in plaats van te proberen de monitor een tokenuitwisseling te laten uitvoeren die hij niet kan doen.
API-checks draaien op een interval van één minuut tot 24 uur - 1, 2, 3, 5, 10, 15, 30 en 45 minuten, daarna 1, 2, 4, 6, 12 en 24 uur - en een nieuwe monitor staat standaard op drie minuten. Ze draaien vanaf de publieke checkpointvloot van HostTracker, die 300+ checkpoints in 158 steden omvat, en jij kiest welke locaties een bepaalde monitor gebruikt. Vanaf meerdere regio's draaien doet er bij een API meer toe dan bij een website: een endpoint achter een CDN of een geo-gerouteerde load balancer kan in de ene regio prima gezond zijn en in de andere falen, en een check vanaf één locatie kan dat simpelweg niet zien. Het stuurt ook de controle op vals alarm - wanneer één checkpoint een storing meldt, wordt de check herhaald vanaf andere onafhankelijke checkpoints, en de statusverandering wordt pas bevestigd zodra het quorum het eens is, zodat één instabiel netwerkpad tussen een datacenter en je host niemand oproept.
Wanneer een API-monitoringcheck faalt - omdat het endpoint niet reageerde, een onverwacht content type teruggaf, of niet de waarden bevatte die je validatiebeleid vereist - stuurt HostTracker een melding via een van zijn 9 notificatiekanalen die je hebt geconfigureerd, waaronder e-mail, sms, spraakoproep, webhooks, Slack en berichten-apps zoals Telegram, Discord en Viber. Zo weet je team direct wanneer een API kapot of verslechterd is, in plaats van pas via een supportticket nadat de integratie al urenlang stilletjes had gefaald. Omdat de check zowel bereikbaarheid als inhoud beoordeelt, weerspiegelt de melding een echt functioneel probleem met de API in plaats van slechts een tijdelijke connectiviteitshapering, wat helpt om zowel gemiste incidenten als onnodige ruis te voorkomen.
Ontdek meer HostTracker-monitoring
Simuleer meerstaps checkout- en inlogflows
Modelleer echte gebruikersreizen - inloggen, zoeken, afrekenen - en krijg direct een melding zodra een stap in de flow faalt of een pagina niet meer correct reageert.
Volg de echte paginalaadsnelheid vanaf 300+ locaties
Automatiseer een echt browserbezoek aan je pagina en meet de laadtijd tegen het beleid dat je instelt, zodat vertragingen aan het licht komen voordat bezoekers afhaken.
Bekijk alle monitoringfuncties van HostTracker
Vergelijk alle 8 monitoringtypes naast elkaar en combineer de controles die bij jouw site passen.
Monitor je API-endpoints 24/7
Start een gratis proefperiode en krijg direct een melding zodra een endpoint de verkeerde status teruggeeft, zijn contract breekt of vertraagt.
Onderdeel van de website-monitoringdienst van HostTracker.