Synthetische transactiemonitoring
HostTracker's transactiemonitoring voor websites doorloopt een echte gebruikersreis - inloggen, zoeken, toevoegen aan winkelwagen, afrekenen - in een echte browser vanaf 300+ locaties, en waarschuwt u zodra een stap faalt.
Hoe een transactiecontrole verloopt, van de eerste stap tot de melding
Elke run, van de eerste navigatie tot het oordeel.
Geen macro-recorder die verouderd raakt. Geef de stappen een naam - die naam is wat de melding zegt.
checkout · 5 stappen · 3.6 s
0 navigate https://shop.example.com/ 1.4 s 1 type #email "[email protected]" 0.2 s 2 click #add-to-cart 0.9 s 3 waitForNavigation /checkout 1.1 s 4 checkContent "Order summary" present 0.1 s
navigate, click, type, select, checkContent, hover, waitForNavigation, sleep, screenshot en back - elk met een eigen timeout en naam.
Elke foutmelding in de browserconsole laat de controle mislukken, met een toegestane lijst van maximaal tien substrings voor een luidruchtig extern script.
Maak en bewerk transactiemonitors via REST, de SDKs, Terraform of MCP - met de volledige actieset inbegrepen.
Meer informatieBegin met de ene reis waarvan het uitvallen u geld kost, zorg dat deze groen staat, en voeg pas daarna de rest toe. Eén gemonitorde flow die u vertrouwt is beter dan vijf half geconfigureerde.
Open een productpagina, klik op toevoegen aan winkelwagen, toets dat het winkelwagenbadge één item toont, open de checkout, toets dat het totaalbedrag en het betaalformulier zijn weergegeven. Stop één stap voor de bestelling wordt geplaatst en u krijgt volledige dekking zonder testbestellingen in uw database.
Typ de inloggegevens van een speciaal testaccount, verstuur, wacht op de navigatie en toets vervolgens op tekst die alleen bestaat zodra de sessie echt is. Dit is voor de meeste applicaties het meest waardevolle scenario - een kapotte login is een volledige storing die op elke pagina 200 blijft teruggeven.
Vul de velden in, verstuur, toets op de bedanktekst. Een stilzwijgend kapot formulier is de klassieke onzichtbare storing: er is geen foutmelding, er gaat geen alarm af, en de aanvragen komen simpelweg niet meer binnen totdat iemand het weken later opmerkt.
Typ een zoekopdracht die altijd iets moet opleveren, verstuur, en toets vervolgens zowel dat een bekend resultaat aanwezig is als dat de tekst voor lege resultaten afwezig is. Die tweede assertie signaleert een zoekindex die stilletjes is gestopt met herbouwen.
Doorloop het registratieformulier tot het laatste bevestigingsscherm en toets hierop, waarbij het formulier naar een testdoel wijst zodat monitoring nooit echte accounts aanmaakt. Aanmelden gaat stilzwijgend en kostbaar kapot - niemand klaagt over een aanmelding die hij niet kon voltooien.
Vraag een reset aan en toets dat het bevestigingsscherm verschijnt. Dit hangt af van uw mailpijplijn, uw wachtrij en uw tokenservice, waardoor het een uitzonderlijk goede kanarie is voor backendproblemen die de voorpagina nooit laat zien.
De transactiecontrole van HostTracker zorgt ervoor dat elke fase van een online transactieproces correct werkt. Elke stap wordt getest, van het toevoegen van artikelen aan de winkelwagen tot het afronden van een aankoop. Zo worden problemen die klanten ervan weerhouden te kopen snel gevonden en opgelost, wat de klantervaring verbetert en omzetverlies vermindert.
De transactiecontrole van HostTracker is volledig en dekt alle aspecten van een e-commercetransactie. Denk aan het invullen van formulieren, klikken op knoppen en doorverwijzingen tussen pagina's, precies zoals een echte bezoeker dat doet. Zo wordt het volledige aankoopproces getest om te zorgen dat alles goed werkt. Daarnaast krijgt u gedetailleerde logs en rapporten waarmee beheerders problemen snel opsporen en oplossen, zonder de aankoopervaring van uw klanten te verstoren.
Transactiecontroles maken e-commercewebsites betrouwbaarder en efficiënter. Ze zorgen dat transacties soepel blijven verlopen doordat problemen worden opgelost voordat ze zich voordoen. Dat betekent tevredener klanten die meer vertrouwen hebben in uw site, en minder gemiste verkopen. Daarmee is het een waardevol hulpmiddel voor elke webshop.
De stap bij naam, de screenshot ervan, en de tijd van elke stap ervoor.
Het resultaat en de melding dragen de naam van de stap, zodat "down" "3 - submit login stopped redirecting" wordt.
Vastgelegd wanneer een stap mislukt, naast die genomen na de laatste stap - hoe de pagina eruitzag onderweg.
Websites, servers, API's, certificaten. Eén controletype per pagina, met dezelfde locaties, meldingen en rapporten erachter.
"Ik werk al lang met deze monitoringdienst en mijn dagelijkse routine is geen probleem meer. Hij houdt stilletjes al mijn sites in de gaten en laat me reageren zodra er iets misgaat."
Vertrouwd door teams bij
Elk hoofdstuk opent ter plekke, zodat de pagina kort blijft.
Synthetische monitoring betekent dat het verkeer doelbewust wordt gegenereerd: in plaats van te wachten tot een bezoeker tegen een probleem aanloopt en te hopen dat hij dit meldt, doorloopt een monitoringdienst uw site zelf, volgens een vast schema, van buiten uw netwerk. Transactiemonitoring is de meerstaps variant hiervan. Een eenvoudige synthetische check vraagt één URL op en bekijkt het antwoord. Een transactiecheck opent een echte browser, doorloopt een vast scenario - de pagina openen, inloggen, zoeken, iets aan de winkelwagen toevoegen, afrekenen - en toetst bij elke stap wat hij aantreft.
Dat verschil is belangrijk omdat wat klanten op een website daadwerkelijk doen meestal een reeks stappen is, geen enkele paginaweergave. Elke afzonderlijke pagina in een checkout kan HTTP 200 teruggeven terwijl de checkout zelf kapot is: een knop die door een release is verwijderd, een formulier dat naar een endpoint post dat nu een 404 geeft, een JavaScript-fout die de wizard bij stap drie laat vastlopen. Niets van die storingen is terug te zien in een statuscode, dus niets ervan komt naar voren in gewone uptime-monitoring.
Niet hetzelfde als financiële transactiemonitoring. In de bankwereld en compliance betekent "transaction monitoring" het screenen van betalingen op fraude en witwassen. Deze pagina gaat over de betekenis binnen webbeheer: het automatisch herhalen van een gebruikersreis op uw eigen website om te bewijzen dat deze nog steeds werkt. HostTracker is een website-monitoringdienst - hij bewaakt uw checkoutflow, niet uw betalingsgrootboek.
Een snelle HTTP-check is het juiste middel voor de vraag "is de site bereikbaar". Het is één verzoek, dus het oordeel is één antwoord: de statuscode, de reactietijd en het trefwoord of de assertieregel die u instelt op de ontvangen inhoud. Dat is veel dekking voor heel weinig kosten - en het stopt precies waar het eerste antwoord eindigt. Alles onder de streep in deze tabel gebeurt na dat punt.
| Wat er daadwerkelijk kapot ging | Snelle HTTP-check | Transactiecheck |
|---|---|---|
| Server onbereikbaar, DNS-storing, TLS-handshake geweigerd | Gesignaleerd | Gesignaleerd |
| De landingspagina geeft 500 terug na een release | Gesignaleerd | Gesignaleerd |
| De pagina laadt, maar de knop "Toevoegen aan winkelwagen" is door een release verwijderd | Gemist - de HTML geeft nog steeds 200 terug | Gesignaleerd - de klikstap kan zijn selector niet vinden |
| Het inlogformulier post naar een endpoint dat nu een 404 geeft | Gemist - de pagina van het formulier zelf is in orde | Gesignaleerd - de stap na het versturen bereikt de accountpagina nooit |
| Een JavaScript-uitzondering stopt de checkoutwizard bij stap twee | Gemist - JavaScript wordt nooit uitgevoerd | Gesignaleerd - de browser voert het script uit, en de check kan falen op consolefouten |
| De betaalpagina toont een foutmelding in plaats van de bevestiging | Gemist - een weergegeven fout is nog steeds een 200 | Gesignaleerd - een inhoudsassertie op de bevestigingstekst faalt |
| De sessiecookie wordt niet meer ingesteld, waardoor stap drie terugspringt naar de inlogpagina | Gemist - er is geen sessie om te verliezen | Gesignaleerd - één browsersessie doorloopt het hele scenario |
| Een script van derden - chatwidget, tag manager, betaal-SDK - blokkeert het renderen | Gemist - assets van derden worden nooit opgehaald | Gesignaleerd - de browser haalt ze op zoals een bezoeker dat doet |
| De flow werkt, maar elke stap duurt nu acht seconden | Gedeeltelijk - alleen het eerste antwoord wordt getimed | Gesignaleerd - elke stap wordt getimed, en een stap kan een time-out krijgen |
Geen van beide checks vervangt de andere. Het eerlijke advies is om beide te gebruiken: een HTTP-check elke minuut op dezelfde site voor snelle detectie van storingen, en een transactiecheck op de ene of twee reizen die daadwerkelijk omzet opleveren. Wilt u eerst het beschikbaarheidsdeel regelen, begin dan met gedistribueerde beschikbaarheidsmonitoring vanaf 300+ checkpoints en voeg de flow er later aan toe.
Elke run start een echte, headless Chromium-browser op een van de checkpoints van HostTracker en geeft die browser één sessie voor het hele scenario. Juist dat detail maakt de check zinvol: cookies, tokens en inlogstatus die in stap twee zijn ingesteld, zijn in stap vijf nog steeds aanwezig, precies zoals bij iemand die door uw site klikt. JavaScript wordt uitgevoerd, doorverwijzingen worden gevolgd - inclusief die uw eigen scripts activeren - en assets van derden laden zoals ze ook in de browser van een bezoeker zouden laden.
Het scenario is sequentieel en fail-fast. Stappen worden uitgevoerd in de volgorde waarin u ze hebt geschreven, en de eerste stap die faalt beëindigt de run en wordt gerapporteerd als oorzaak. U krijgt nooit een muur van downstream-fouten veroorzaakt door één kapotte knop - u krijgt de kapotte knop.
Twee optionele schakelaars bepalen hoe streng een run is. Falen bij consolefout maakt van elke consolefout in de browser een mislukte check - krachtig bij een nette applicatie, en gecombineerd met een toegestane lijst van maximaal tien subtekenreeksen zodat een bekend luidruchtig script van derden geen loos alarm slaat. Media niet laden staat standaard aan; schakel dit uit wanneer juist de media zelf onderdeel is van wat u test.
Een transactie is een lijst met stappen, en elke stap is één actie op de pagina. Er is geen macrorecorder die kan verouderen - u bouwt het scenario expliciet op, wat ook de reden is dat het blijft werken wanneer uw marketingteam de tekst op een knop wijzigt.
| Actie | Wat de stap doet |
|---|---|
| navigate | Opent een URL. De eerste navigatie - naar het eigen adres van de monitor - wordt automatisch als stap nul toegevoegd. |
| click | Klikt op een element dat via een CSS-selector wordt gevonden, of op een viewportcoördinaat. Links, rechts of middelste knop, met een optionele vasthoudvertraging. |
| type | Typt tekst in een veld, optioneel met een vertraging tussen toetsaanslagen zodat de eigen invoerhandlers van de pagina kunnen bijhouden. |
| select | Toetst de kardinaliteit van een selector: deze moet niets, precies één element, minstens één of een willekeurig aantal matchen. Werkt op alle matches, de eerste, of een willekeurige. |
| checkContent | Toetst de weergegeven tekst. Tot tien trefwoorden, een deel of alle, hoofdlettergevoelig of niet, aanwezig of juist bewust afwezig, en optioneel alleen in de zichtbare tekst. |
| hover | Beweegt de muis over een element - zo bereikt u een menu of tooltip dat alleen bij mouse-over verschijnt. |
| waitForNavigation | Wacht tot de pagina navigeert, en laat de stap optioneel falen als er niet op tijd wordt genavigeerd. |
| sleep | Pauzeert, van 1 milliseconde tot 10 seconden, met optionele willekeurige variatie zodat een scenario niet elke run exact hetzelfde moment raakt. |
| screenshot | Legt de pagina vast tijdens de flow, zodat een storing twee stappen later u nog steeds laat zien hoe de pagina er onderweg uitzag. |
| back | Gaat één stap terug in de browsergeschiedenis. |
Elke stap kan achteraf een screenshot en een wait-for-navigation krijgen, een eigen aangepaste time-out, en een korte naam van maximaal 19 tekens. Geef uw stappen een naam - die naam verschijnt in het resultaat en in de melding, dus "3 - login versturen" maakt het verschil tussen een pagina die "down" is en een pagina waarvan de login-POST is gestopt met doorverwijzen. In de webeditor worden screenshots en navigatiewachttijden aangeboden als gedrag na een stap; de volledige actieset inclusief hover is beschikbaar via de API.
id of een data--attribuut dat u
zelf beheert, geen gegenereerde classname die bij de volgende build verandert.checkContent-stap na elke betekenisvolle overgang maakt van
een reeks kliks een echte test: toets na het inloggen de tekst van de accountpagina; toets na de
checkout de bevestigingstekst.Wilt u de startURL controleren voordat u het scenario bouwt, voer dan een gratis directe HTTP-check erop uit - geen inloggen nodig - of meet hoe de pagina laadt in een echte browser met de gratis paginasnelheidstest.
De run stopt bij de falende stap en legt vast wat er is waargenomen. Het resultaat benoemt de stap, classificeert de storing - een time-out, een element dat de selector niet kon vinden, een inhoudsassertie die niet overeenkwam, een HTTP-fout, een verbindingsfout, een consolefout in de browser, of een verkeerd geconfigureerde stap - en bewaart de duur per stap, de URL, het IP-adres en de HTTP-status waar elke navigatie op uitkwam, de consolemeldingen van de browser, en een screenshot van de pagina op het moment dat het misging.
Daarna wordt dit dubbel gecontroleerd voordat er iemand wordt gewekt. Eén enkele mislukte waarneming wordt niet als storing behandeld: de check wordt opnieuw uitgevoerd vanaf extra onafhankelijke checkpoints, en de statusverandering wordt pas bevestigd wanneer het quorum het daarmee eens is. Standaard geldt een meerderheidsoordeel over maximaal zeven agents met een minimum van drie - zodat één instabiel checkpoint, of één tijdelijke netwerkhapering tussen een datacenter en uw host, niet op eigen houtje een melding kan veroorzaken.
Zodra de overgang is bevestigd, volgt de melding de vertraging die elk contact heeft gekozen: direct, of pas na 3, 5, 15, 30 of 60 minuten, of na 3, 6, 12 of 24 uur ononderbroken storing. Meldingen worden verstuurd via de negen notificatiekanalen die HostTracker ondersteunt - e-mail, sms, spraakoproep, webhook, Slack, webpush en de berichten-apps Telegram, Discord en Viber - en er volgt een hersteld-melding zodra de flow weer succesvol wordt voltooid.
Een transactiecheck is de krachtigste monitor die HostTracker biedt, en degene met de meeste praktische beperkingen. Als u die vooraf kent, bespaart u een middag.
De twee aanpakken beantwoorden verschillende vragen, en een team dat het verschil begrijpt, verwacht niet langer dat de ene het werk van de andere overneemt. HostTracker is een synthetische website-monitoringdienst: het genereert het verkeer zelf, vanaf zijn eigen checkpoints, volgens een schema dat u zelf bepaalt.
| Synthetische transactiemonitoring | Real-user monitoring | |
|---|---|---|
| Wie genereert het verkeer | De monitoringdienst, volgens een vast schema | Uw echte bezoekers, wanneer ze toevallig langskomen |
| Werkt voordat u verkeer hebt | Ja - een stagingsite zonder gebruikers wordt nog steeds gecontroleerd | Nee - geen bezoekers, geen data |
| Merkt een storing om 3 uur 's nachts op | Ja - het schema slaapt niet | Pas als er iemand langskomt |
| Benoemt de exacte stap die faalde | Ja - het scenario is deterministisch | Zelden - u ziet het symptoom, niet de reeks |
| Weerspiegelt wat echte klanten hebben ervaren | Nee - het is een gecontroleerde steekproef | Ja - dat is precies het punt |
| Vereist code op uw site | Nee - het draait volledig van buitenaf | Een script of SDK op elke pagina |
| Dekt een flow die klanten zelden voltooien | Ja - u kiest zelf wat wordt getest | Nee - zeldzame paden blijven ongemeten |
Wilt u vervolgens liever het tijdsdeel dan het flowdeel, dan meet HostTracker ook echte laadtijden van pagina's in de browser - zie browsertoegang en paginalaadtijd - en voor het machine-naar-machine-equivalent van een transactie valideert een API-monitoringcheck het responscontract in plaats van de weergegeven pagina. Server-side verklaart een databasequerymonitor vaak waarom een flow in de eerste plaats traag werd.
Transactiemonitoring voor een website is een controle die een echte, meerstaps gebruikersflow automatiseert - zoals het invullen van een formulier, inloggen, een artikel aan de winkelwagen toevoegen of een aankoop afronden - en verifieert dat elke stap correct wordt voltooid en dat de hele reeks het verwachte resultaat oplevert. In tegenstelling tot een eenvoudige check die alleen bevestigt dat één pagina laadt, volgt transactiemonitoring exact het pad dat een echte bezoeker zou afleggen: gegevens invoeren en achtereenvolgens door pagina's klikken, waarna het resultaat wordt getoetst aan de regels die u zelf bepaalt. Dit is belangrijk omdat een website er volgens elke eenvoudige beschikbaarheidsmeting kerngezond kan uitzien - de homepage laadt, losse pagina's geven statuscode 200 terug - terwijl een cruciaal, meerstaps proces zoals de checkout ergens halverwege stilletjes kapot is. De transactiemonitoring van HostTracker is speciaal gebouwd om precies dit type storing op te sporen.
De transactiemonitoring van HostTracker kan een breed scala aan website-interacties automatiseren en valideren, waaronder het invullen van formulieren, klikken op knoppen en doorverwijzingen tussen pagina's die samen nabootsen hoe een echte gebruiker zich over uw site beweegt. Dit dekt veelvoorkomende scenario's zoals het afronden van een registratie- of inlogflow, het versturen van een contact- of leadformulier, en meerstaps aankoopprocessen zoals het toevoegen van artikelen aan de winkelwagen en het doorlopen van de checkout. Omdat de check het gedrag van een echte gebruiker stap voor stap simuleert in plaats van slechts één pagina te laden, kan worden geverifieerd dat elke fase van het proces daadwerkelijk werkt en het verwachte resultaat oplevert - niet alleen dat de betrokken pagina's toevallig laden. Dit maakt het nuttig voor elke website waar een kapotte interactieve flow - niet alleen een kapotte pagina - u leads, aanmeldingen of omzet zou kosten.
Basale uptime-monitoring controleert alleen of één pagina of endpoint reageert en een normale statuscode teruggeeft, wat aangeeft dat de server bereikbaar is, maar niets zegt over of een meerstaps proces daarbovenop daadwerkelijk werkt. Transactiemonitoring gaat een stap verder door een volledige reeks stappen te automatiseren - een formulier versturen, door pagina's klikken, een aankoopflow afronden - en te verifiëren dat elke stap slaagt en dat het hele proces van begin tot eind het juiste resultaat oplevert. Een website kan elke uptime-check doorstaan terwijl het checkoutproces volledig kapot is bij de betaalstap, omdat elke afzonderlijke pagina op zichzelf gewoon blijft laden; alleen een check die de transactie daadwerkelijk doorloopt, zou dat opmerken. Voor elke site waar conversies afhangen van een meerstaps flow, dekt transactiemonitoring een categorie storingen die basale uptime-checks simpelweg niet kunnen zien.
Ja, dit is een van de belangrijkste toepassingen van transactiemonitoring. De transactiechecks van HostTracker doorlopen een vastgelegde reeks stappen - zoals een artikel aan de winkelwagen toevoegen, naar de checkout gaan, verplichte velden invullen en een bevestigingspagina bereiken - en verifiëren onderweg dat elke stap verloopt zoals verwacht. Dit betekent dat een storing die ergens in de flow ontstaat - of het nu een kapotte "toevoegen aan winkelwagen"-knop is, een bug in de formuliervalidatie, of een checkoutpagina die na een recente release niet meer laadt - wordt gedetecteerd en gemeld met gedetailleerde logs die precies naar de stap wijzen die faalde. Dit snel opsporen is belangrijk, want een kapotte checkoutstap kost direct omzet, en kan lange tijd onopgemerkt blijven bij eenvoudige uptime-checks omdat de betrokken pagina's afzonderlijk nog steeds normale statuscodes kunnen teruggeven.
Wanneer een stap in een transactiecheck faalt - een formulier wordt niet verstuurd, een verwachte pagina laadt niet, of aan een validatieregel wordt niet voldaan - registreert HostTracker het exacte moment van falen en stuurt een melding via de door u ingestelde notificatiekanalen, zodat u niet alleen weet dát er iets kapot is, maar ook wáár in de flow dit gebeurde. Bij de melding horen gedetailleerde logs en rapporten, die beheerders de specifieke stap en uitkomst geven die nodig zijn om snel te onderzoeken, in plaats van de hele flow handmatig na te moeten lopen. Dit detailniveau per stap is wat transactiemonitoring in de praktijk zo bruikbaar maakt om problemen snel op te lossen: weten dat "de checkout kapot is" is veel minder bruikbaar dan weten dat de storing specifiek optreedt bij de betaalbevestiging na een bepaalde recente wijziging, wat de waarschijnlijke oorzaak aanzienlijk versmalt.
Nee, hoewel meerstaps aankoopflows een veelvoorkomend voorbeeld zijn, is transactiemonitoring nuttig voor elke website waar een reeks gebruikersacties - niet slechts het laden van één pagina - correct moet verlopen. Denk aan login- en registratieflows voor SaaS-toepassingen, lead- en contactformulieren voor dienstverleners, meerpaginaprocessen voor aanvragen, en elke sitenavigatie waarbij een kapotte link of een mislukte formulierinzending halverwege een bezoeker ervan weerhoudt te voltooien waarvoor hij kwam. Elk interactief proces waarbij het kwijtraken van een gebruiker halverwege echte kosten met zich meebrengt - een gemiste aanmelding, een verlaten leadformulier, een onvolledige aanvraag - heeft baat bij het automatiseren en regelmatig controleren van die specifieke flow, in plaats van aan te nemen dat alles nog werkt simpelweg omdat de betrokken pagina's foutloos laden.
Een transactiecheck draait op een interval dat u zelf kiest tussen 10 minuten en 24 uur - 10, 15, 30 en 45 minuten, daarna 1, 2, 4, 6, 12 en 24 uur. De ondergrens ligt hoger dan de minuut die HostTracker biedt voor eenvoudige HTTP-checks, en dat is bewust zo: een transactiecheck start een echte browser, laadt de pagina met de bijbehorende JavaScript en doorloopt uw scenario stap voor stap, wat seconden echt werk kost in plaats van één enkel verzoek. Het gebruikelijke patroon is om beide te combineren - een HTTP- of pingcheck van één minuut beantwoordt de vraag "is de site op dit moment bereikbaar", en een transactiecheck elke 10 of 15 minuten beantwoordt de lastigere vraag of de checkout, de login of de aanmeldingsflow erachter nog steeds volledig lukt. Die combinatie signaleert een harde storing binnen een minuut en een kapotte flow binnen één controlecyclus, zonder dat elke zestig seconden een browsersessie tegen uw applicatie wordt gestart.
Nee, en dat zou u ook niet moeten doen. Een transactiecheck verstuurt echte formulieren naar uw echte site, dus de juiste opzet is een speciaal testaccount, een testproduct of -SKU, en - als de flow tot aan de betaling reikt - de sandbox- of testkaartmodus van uw betalingsprovider, precies zoals u dat zou doen voor elke geautomatiseerde end-to-end-test. Veel teams stoppen het gemonitorde scenario één stap voor de onomkeerbare actie: de betaalpagina bereiken, toetsen dat deze met het juiste totaalbedrag is weergegeven, en daar stoppen. Dat bewijst nog steeds dat elke stap tot aan het aankooppunt werkt, zonder dat er elke tien minuten een bestelling wordt aangemaakt. Dezelfde regel geldt voor aanmeldings- en leadflows: richt het scenario op een testformulier, of filter de inzendingen van de monitor aan uw kant eruit, zodat monitoringverkeer nooit uw echte data vervuilt.
Start een gratis proefperiode en monitor uw belangrijkste gebruikersflows - inloggen, zoeken, checkout - dag en nacht.
Onderdeel van de website monitoring software van HostTracker.