Monitoraggio sintetico delle transazioni
Il monitoraggio delle transazioni di HostTracker riproduce un percorso reale dell'utente - accedere, cercare, aggiungere al carrello, effettuare il checkout - in un browser reale da oltre 300 località, e ti avvisa nel momento in cui un passaggio si interrompe.
Come si svolge un controllo di transazione, dal primo passo all'avviso
Ogni esecuzione, dalla prima navigazione al verdetto.
Nessun registratore di macro che diventa obsoleto. Dai un nome ai passaggi - quel nome è ciò che dice l'allerta.
checkout · 5 passaggi · 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 e back - ciascuna con il proprio timeout e il proprio nome.
Qualsiasi errore nella console del browser fa fallire il controllo, con una lista consentita fino a dieci sottostringhe per uno script di terze parti rumoroso.
Crea e modifica monitor di transazione tramite REST, gli SDK, Terraform o MCP - con l'intero set di azioni incluso.
Scopri di piùInizia con l'unico percorso il cui guasto ti costa denaro, portalo al verde, e solo dopo aggiungi il resto. Un flusso monitorato di cui ti fidi vale più di cinque configurati a metà.
Apri una pagina prodotto, clicca su aggiungi al carrello, verifica che il badge del carrello mostri un articolo, apri il checkout, verifica che il totale e il modulo di pagamento siano stati visualizzati. Fermati un passaggio prima che l'ordine venga effettuato e ottieni una copertura completa senza ordini di prova nel tuo database.
Digita le credenziali di un account di test dedicato, invia, attendi la navigazione, poi verifica un testo che esiste solo quando la sessione è reale. Questo è lo scenario di maggior valore in assoluto per la maggior parte delle applicazioni - un login rotto è un'interruzione totale che restituisce comunque 200 su ogni pagina.
Compila i campi, invia, verifica il testo di ringraziamento. Un modulo rotto silenziosamente è la classica interruzione invisibile: nulla genera errori, nulla avvisa, e le richieste smettono semplicemente di arrivare finché qualcuno non se ne accorge settimane dopo.
Digita una query che deve sempre trovare qualcosa, invia, poi verifica sia che un risultato noto sia presente sia che il testo di stato vuoto sia assente. Quella seconda verifica è ciò che individua un indice di ricerca che ha smesso silenziosamente di ricostruirsi.
Percorri il modulo di registrazione fino alla schermata di conferma finale e verificala, puntando il modulo verso un target di test così il monitoraggio non crea mai account reali. La registrazione si rompe silenziosamente e a caro prezzo - nessuno si lamenta di una registrazione che non è riuscito a completare.
Richiedi una reimpostazione e verifica che compaia la schermata di conferma. Dipende dalla tua pipeline di posta, dalla tua coda e dal tuo servizio dei token, quindi è un canarino insolitamente efficace per problemi di backend che la pagina principale non mostra mai.
Il servizio di controllo transazionale di HostTracker garantisce che tutte le fasi di un processo di transazione online funzionino correttamente. Testa ogni passaggio del processo, dall'aggiunta di articoli al carrello fino al completamento dell'acquisto. Questo aiuta a individuare e risolvere problemi che potrebbero impedire ai clienti di acquistare, migliorando l'esperienza del cliente e riducendo le vendite perse.
La funzione di controllo transazionale di HostTracker è completa e copre vari aspetti di una transazione e-commerce. Include elementi come invii di moduli, clic sui pulsanti e reindirizzamenti tra pagine, per riprodurre il comportamento reale degli utenti. Questo testa l'intero processo di acquisto per assicurarsi che funzioni correttamente. Fornisce inoltre log e report dettagliati per aiutare gli amministratori a individuare e risolvere rapidamente eventuali problemi, senza incidere sul percorso d'acquisto dell'utente.
I controlli transazionali rendono i siti e-commerce più affidabili ed efficienti. Aiutano a mantenere le transazioni fluide, risolvendo i problemi prima che si verifichino. Questo significa clienti più soddisfatti e più fiduciosi nel sito. Aiuta inoltre a mantenere i clienti soddisfatti evitando vendite perse. Uno strumento utile per qualsiasi negozio online.
Il passaggio con il suo nome, il suo screenshot e i tempi di ogni passaggio precedente.
Il risultato e l'allerta riportano il nome del passaggio, così "down" diventa "3 - submit login stopped redirecting".
Acquisito quando un passaggio fallisce, accanto a quello scattato dopo l'ultimo passaggio - com'era la pagina lungo il percorso.
Siti web, server, API, certificati. Un tipo di controllo per pagina, con le stesse località, avvisi e report alle spalle.
"Lavoro con questo servizio di monitoraggio da molto tempo e la mia routine quotidiana non è più un problema. Controlla silenziosamente tutti i miei siti e mi permette di reagire nel momento in cui qualcosa va storto."
Scelto da team come
Ogni capitolo si apre sul posto, così la pagina resta breve.
Il monitoraggio sintetico significa che il traffico viene generato di proposito: invece di aspettare che un visitatore incontri un problema sperando che te lo segnali, un servizio di monitoraggio visita il tuo sito da solo, secondo una pianificazione, dall'esterno della tua rete. Il monitoraggio delle transazioni ne è la forma multi-fase. Un semplice controllo sintetico richiede un URL e osserva la risposta. Un controllo transazionale apre un browser reale, percorre uno scenario ordinato - apri la pagina, accedi, cerca, aggiungi al carrello, effettua il checkout - e verifica ciò che trova a ogni passaggio.
La differenza è importante perché gran parte di ciò che i clienti fanno davvero su un sito web è una sequenza, non la visualizzazione di una pagina. Ogni singola pagina di un checkout può restituire HTTP 200 mentre il checkout stesso è rotto: un pulsante rimosso da un rilascio, un modulo che invia dati a un endpoint che ora restituisce 404, un errore JavaScript che blocca la procedura guidata al terzo passaggio. Nulla di questi guasti compare in un codice di stato, quindi nulla di essi compare in un normale monitoraggio uptime.
Non è la stessa cosa del monitoraggio delle transazioni finanziarie. Nel settore bancario e nella compliance, "monitoraggio delle transazioni" indica il controllo dei pagamenti alla ricerca di frodi e riciclaggio di denaro. Questa pagina riguarda il significato legato alle operazioni web: riprodurre automaticamente il percorso di un utente sul tuo sito per dimostrare che funziona ancora. HostTracker è un servizio di monitoraggio di siti web - controlla il tuo flusso di checkout, non il tuo registro dei pagamenti.
Un controllo HTTP veloce è lo strumento giusto per rispondere a "il sito è attivo". È una singola richiesta, quindi il suo verdetto è una singola risposta: il codice di stato, il tempo di risposta e qualsiasi regola di parola chiave o di verifica impostata sul corpo ricevuto. È una copertura notevole per un costo molto basso - e si ferma esattamente dove finisce la prima risposta. Tutto ciò che si trova sotto la linea in questa tabella accade dopo quel punto.
| Cosa si è realmente rotto | Controllo HTTP veloce | Controllo transazionale |
|---|---|---|
| Server irraggiungibile, errore DNS, handshake TLS rifiutato | Rilevato | Rilevato |
| La pagina di destinazione restituisce 500 dopo un rilascio | Rilevato | Rilevato |
| La pagina si carica, ma il pulsante "Aggiungi al carrello" è stato rimosso da un rilascio | Non rilevato - l'HTML restituisce comunque 200 | Rilevato - il passaggio di clic non riesce a risolvere il proprio selettore |
| Il modulo di login invia dati a un endpoint che ora restituisce 404 | Non rilevato - la pagina del modulo funziona normalmente | Rilevato - il passaggio successivo all'invio non raggiunge mai la pagina dell'account |
| Un'eccezione JavaScript blocca la procedura guidata di checkout al secondo passaggio | Non rilevato - il JavaScript non viene mai eseguito | Rilevato - il browser esegue lo script e il controllo può fallire in presenza di errori in console |
| La pagina di pagamento mostra un banner di errore invece della conferma | Non rilevato - un errore visualizzato resta comunque un 200 | Rilevato - una verifica sul contenuto del testo di conferma fallisce |
| Il cookie di sessione smette di essere impostato, quindi il terzo passaggio rimanda alla pagina di login | Non rilevato - non c'è alcuna sessione da perdere | Rilevato - un'unica sessione del browser esegue l'intero scenario |
| Uno script di terze parti - widget di chat, tag manager, SDK di pagamento - blocca il rendering | Non rilevato - le risorse di terze parti non vengono mai recuperate | Rilevato - il browser le recupera proprio come farebbe un visitatore |
| Il flusso funziona ma ogni passaggio richiede ora otto secondi | Parzialmente - viene cronometrata solo la prima risposta | Rilevato - ogni passaggio è cronometrato e può andare in timeout |
Nessuno dei due controlli sostituisce l'altro. Il consiglio onesto è eseguirli entrambi: un controllo HTTP a un minuto sullo stesso sito per un rilevamento rapido delle interruzioni, e un controllo transazionale sui percorsi che generano davvero fatturato - uno o due. Se vuoi partire dalla metà relativa alla disponibilità, inizia con il monitoraggio della disponibilità distribuito da oltre 300 postazioni e aggiungi il flusso sopra.
Ogni esecuzione avvia un vero browser Chromium headless su una delle postazioni di HostTracker e gli assegna un'unica sessione del browser per l'intero scenario. Questo singolo dettaglio è ciò che rende il controllo significativo: i cookie, i token e lo stato di accesso impostati al secondo passaggio sono ancora presenti al quinto, esattamente come accadrebbe per una persona che naviga sul tuo sito. Il JavaScript viene eseguito, i reindirizzamenti vengono seguiti - inclusi quelli innescati dai tuoi stessi script - e le risorse di terze parti si caricano come farebbero nel browser di un visitatore.
Lo scenario è sequenziale e a interruzione immediata. I passaggi vengono eseguiti nell'ordine in cui li hai scritti, e il primo passaggio che fallisce termina l'esecuzione e diventa la causa segnalata. Non ottieni mai un muro di errori a valle causati da un pulsante rotto - ottieni direttamente il pulsante rotto.
Due interruttori opzionali cambiano il livello di rigore dell'esecuzione. Fallisci in caso di errore in console trasforma qualsiasi errore della console del browser in un controllo fallito - potente su un'applicazione ben scritta, e abbinabile a una lista di elementi consentiti di massimo dieci sottostringhe, così uno script di terze parti notoriamente rumoroso non genera falsi allarmi. Salta il caricamento dei file multimediali è attivo per impostazione predefinita; disattivalo quando ciò che stai testando è proprio il contenuto multimediale.
Una transazione è un elenco di passaggi, e ogni passaggio è un'azione sulla pagina. Non c'è alcun registratore di macro che possa diventare obsoleto - costruisci lo scenario in modo esplicito, ed è anche per questo che continua a funzionare quando il tuo team marketing cambia il testo di un pulsante.
| Azione | Cosa fa il passaggio |
|---|---|
| navigate | Apre un URL. La prima navigazione - verso l'indirizzo del monitor stesso - viene aggiunta automaticamente come passaggio zero. |
| click | Clicca su un elemento risolto tramite selettore CSS, oppure su una coordinata del viewport. Pulsante sinistro, destro o centrale, con un ritardo di pressione opzionale. |
| type | Digita del testo in un campo, con un ritardo opzionale tra le battute in modo che i gestori di input della pagina riescano a starci dietro. |
| select | Verifica la cardinalità di un selettore: deve corrispondere a nessun elemento, esattamente uno, almeno uno o un numero qualsiasi. Agisce su tutte le corrispondenze, sulla prima o su una casuale. |
| checkContent | Verifica il testo visualizzato. Fino a dieci parole chiave, una qualsiasi o tutte, con o senza distinzione tra maiuscole e minuscole, presenti o deliberatamente assenti, e opzionalmente solo nel testo visibile. |
| hover | Passa il mouse su un elemento - il modo in cui si raggiunge un menu o un tooltip che esiste solo al passaggio del mouse. |
| waitForNavigation | Attende che la pagina navighi, facendo eventualmente fallire il passaggio se la navigazione non avviene in tempo. |
| sleep | Mette in pausa, da 1 millisecondo fino a 10 secondi, con una variazione casuale opzionale così lo scenario non colpisce sempre lo stesso istante a ogni esecuzione. |
| screenshot | Cattura la pagina a metà del flusso, così un guasto due passaggi più avanti ti mostra comunque com'era la pagina in quel momento. |
| back | Torna indietro di una voce nella cronologia del browser. |
Ogni passaggio può includere uno screenshot e un'attesa di navigazione successivi, un proprio timeout personalizzato e un nome breve fino a 19 caratteri. Dai un nome ai tuoi passaggi - il nome è ciò che compare nel risultato e nell'avviso, quindi "3 - invia login" fa la differenza tra una pagina che è "down" e una pagina il cui POST di login ha smesso di reindirizzare. Nell'editor web, screenshot e attese di navigazione sono offerti come comportamenti successivi al passaggio; il set completo di azioni, incluso hover, è disponibile tramite l'API.
id o un attributo data- sotto il
tuo controllo, non un nome di classe generato che cambia con la prossima build.checkContent dopo ogni transizione
significativa è ciò che trasforma una sequenza di clic in un vero test: dopo il login, verifica il
testo della pagina dell'account; dopo il checkout, verifica il testo di conferma.Se vuoi fare un controllo preliminare dell'URL di partenza prima di costruire lo scenario, esegui un controllo HTTP istantaneo gratuito su di esso - senza bisogno di accesso - oppure misura come si carica la pagina in un browser reale con il test di velocità della pagina gratuito.
L'esecuzione si interrompe al passaggio che fallisce e registra ciò che ha rilevato. Il risultato indica il nome del passaggio, classifica il guasto - un timeout, un elemento che il selettore non è riuscito a risolvere, una verifica sul contenuto che non ha corrisposto, un errore HTTP, un errore di connessione, un errore nella console del browser o un passaggio configurato male - e conserva le durate per passaggio, l'URL, l'IP e lo stato HTTP su cui è atterrata ogni navigazione, i messaggi della console del browser e uno screenshot della pagina nel momento in cui si è rotta.
Poi viene ricontrollato prima che qualcuno venga svegliato. Una singola osservazione di fallimento non viene trattata come un'interruzione: il controllo viene rieseguito su ulteriori postazioni indipendenti e il cambio di stato viene confermato solo quando il quorum concorda. Il valore predefinito è un verdetto a maggioranza su un massimo di sette agenti con un minimo di tre - così una singola postazione instabile, o un piccolo problema di rete transitorio tra un data center e il tuo host, non può generare da sola un avviso.
Una volta confermata la transizione, l'invio degli avvisi segue il ritardo scelto da ciascun contatto: immediatamente, oppure solo dopo 3, 5, 15, 30 o 60 minuti, o 3, 6, 12 o 24 ore di guasto continuo. Gli avvisi vengono inviati sui nove canali di notifica supportati da HostTracker - email, SMS, chiamata vocale, webhook, Slack, web push e le app di messaggistica Telegram, Discord e Viber - e segue un avviso di ripristino quando il flusso ricomincia a completarsi correttamente.
Un controllo transazionale è il monitor più potente offerto da HostTracker ed è anche quello con più vincoli pratici. Conoscerli in anticipo ti fa risparmiare un pomeriggio.
I due approcci rispondono a domande diverse, e un team che comprende questa distinzione smette di aspettarsi che uno faccia il lavoro dell'altro. HostTracker è un servizio di monitoraggio sintetico di siti web: genera da sé il traffico, dalle proprie postazioni, secondo una pianificazione che controlli tu.
| Monitoraggio sintetico delle transazioni | Monitoraggio degli utenti reali | |
|---|---|---|
| Chi genera il traffico | Il servizio di monitoraggio, secondo una pianificazione fissa | I tuoi visitatori reali, ogni volta che capitano |
| Funziona prima ancora di avere traffico | Sì - anche un sito di staging senza utenti viene comunque controllato | No - senza visitatori, nessun dato |
| Nota un guasto alle 3 del mattino | Sì - la pianificazione non dorme mai | Non finché non arriva qualcuno |
| Indica il passaggio esatto che è fallito | Sì - lo scenario è deterministico | Raramente - vedi il sintomo, non la sequenza |
| Riflette ciò che i clienti reali hanno vissuto | No - è un campione controllato | Sì - è esattamente il suo scopo |
| Richiede codice sul tuo sito | No - funziona interamente dall'esterno | Uno script o SDK in ogni pagina |
| Copre un flusso che i clienti completano raramente | Sì - scegli tu cosa viene messo alla prova | No - i percorsi rari restano non misurati |
Se ciò che vuoi approfondire dopo è la metà legata ai tempi piuttosto che quella legata al flusso, HostTracker misura anche i caricamenti di pagina in un browser reale - vedi tempistiche di accesso e caricamento pagina da browser - e per l'equivalente machine-to-machine di una transazione, un controllo di monitoraggio API convalida il contratto della risposta invece della pagina visualizzata. Lato server, un monitor delle query al database spesso spiega perché un flusso ha iniziato a rallentare.
Il monitoraggio delle transazioni di un sito web è un controllo che automatizza un flusso reale multi-fase dell'utente - come compilare un modulo, effettuare il login, aggiungere un articolo al carrello o completare un acquisto - e verifica che ogni passaggio si completi correttamente e che l'intera sequenza produca il risultato atteso. A differenza di un controllo semplice che si limita a confermare il caricamento di una singola pagina, il monitoraggio delle transazioni segue lo stesso percorso che compirebbe un visitatore reale, inviando dati e navigando tra le pagine in sequenza, per poi validare il risultato in base alle regole definite dall'utente. Questo è importante perché un sito può apparire perfettamente funzionante secondo ogni semplice misura di disponibilità - la homepage si carica, le singole pagine restituiscono codici di stato 200 - mentre un processo critico multi-fase come il checkout è silenziosamente interrotto a metà. Il monitoraggio delle transazioni di HostTracker è pensato proprio per individuare questa categoria di guasti.
Il monitoraggio delle transazioni di HostTracker può automatizzare e validare una vasta gamma di interazioni sul sito web, tra cui invii di moduli, clic su pulsanti e reindirizzamenti tra pagine che, insieme, riproducono il modo in cui un utente reale naviga sul tuo sito. Questo copre scenari comuni come il completamento di un flusso di registrazione o login, l'invio di un modulo di contatto o di generazione lead, e processi di acquisto multi-fase come l'aggiunta di articoli al carrello e il proseguimento fino al checkout. Poiché il controllo simula passo dopo passo il comportamento reale dell'utente invece di limitarsi a caricare una singola pagina, può verificare che ogni fase del processo funzioni davvero e produca il risultato atteso, non solo che le pagine coinvolte si carichino. Questo lo rende utile per qualsiasi sito web in cui un flusso interattivo interrotto - non solo una pagina non funzionante - farebbe perdere lead, iscrizioni o vendite.
Il monitoraggio uptime di base verifica se una singola pagina o endpoint risponde e restituisce un codice di stato normale, il che indica che il server è raggiungibile ma non dice nulla sul fatto che un processo multi-fase costruito sopra di esso funzioni realmente. Il monitoraggio delle transazioni va oltre, automatizzando un'intera sequenza di passaggi - inviare un modulo, navigare tra le pagine, completare un flusso di acquisto - e verificando che ogni passaggio abbia successo e che il processo end-to-end produca il risultato corretto. Un sito web può superare ogni controllo di uptime mentre il suo processo di checkout è completamente non funzionante nella fase di pagamento, perché ogni singola pagina continua a caricarsi correttamente se considerata isolatamente; solo un controllo che percorre davvero la transazione riuscirebbe a individuarlo. Per qualsiasi sito in cui le conversioni dipendono da un flusso multi-fase, il monitoraggio delle transazioni copre una categoria di guasti che i controlli uptime di base semplicemente non possono vedere.
Sì, questo è uno dei principali casi d'uso del monitoraggio delle transazioni. I controlli transazionali di HostTracker percorrono una sequenza definita di passaggi - come aggiungere un articolo al carrello, procedere al checkout, compilare i campi obbligatori e raggiungere una pagina di conferma - e verificano che ogni passaggio si completi come previsto lungo il percorso. Questo significa che un errore introdotto in qualsiasi punto del flusso, che si tratti di un pulsante "aggiungi al carrello" non funzionante, di un bug nella validazione di un modulo o di una pagina di checkout che non si carica dopo un recente rilascio, viene rilevato e segnalato con log dettagliati che indicano il passaggio specifico in cui si è verificato l'errore. Individuare rapidamente questo tipo di problema è importante perché un passaggio di checkout non funzionante costa vendite direttamente, e può passare inosservato per molto tempo ai semplici controlli uptime, dato che le singole pagine coinvolte possono comunque restituire codici di stato normali.
Quando un passaggio di un controllo transazionale fallisce - un modulo non viene inviato, una pagina attesa non si carica o una regola di validazione non viene rispettata - HostTracker registra il punto di errore e invia un avviso attraverso i canali di notifica configurati, così saprai non solo che qualcosa si è rotto, ma anche in quale punto del flusso è accaduto. Log e report dettagliati accompagnano l'avviso, fornendo agli amministratori il passaggio specifico e il risultato necessari per indagare rapidamente, senza dover ripercorrere manualmente l'intero flusso. Questo livello di dettaglio per singolo passaggio è ciò che rende il monitoraggio delle transazioni davvero utile per risolvere i problemi in fretta: sapere che "il checkout è rotto" è molto meno utile rispetto a sapere che l'errore si verifica specificamente nella fase di conferma del pagamento dopo una particolare modifica recente, il che restringe considerevolmente le possibili cause.
No, sebbene i flussi di acquisto multi-fase siano un esempio comune, il monitoraggio delle transazioni è utile per qualsiasi sito web in cui una sequenza di azioni dell'utente - non solo il caricamento di una singola pagina - deve funzionare correttamente. Questo include i flussi di login e registrazione per applicazioni SaaS, i moduli di generazione lead e contatto per attività di servizi, i processi di richiesta multi-pagina e qualsiasi percorso sul sito in cui un link non funzionante o l'invio fallito di un modulo a metà percorso impedirebbe a un visitatore di completare ciò per cui era arrivato. Qualsiasi processo interattivo in cui perdere un utente a metà percorso comporta un costo reale - un'iscrizione mancata, un modulo lead abbandonato, una richiesta incompleta - trae vantaggio dall'avere quel flusso specifico automatizzato e controllato regolarmente, invece di presumere che funzioni ancora solo perché le singole pagine coinvolte si caricano senza errori.
Un controllo transazionale viene eseguito a un intervallo che scegli tu, tra 10 minuti e 24 ore - 10, 15, 30 e 45 minuti, poi 1, 2, 4, 6, 12 e 24 ore. Il limite minimo è più alto rispetto al minuto che HostTracker offre per i semplici controlli HTTP, e questo è intenzionale: un controllo transazionale avvia un browser reale, carica la pagina con il suo JavaScript e percorre lo scenario passo dopo passo, il che richiede secondi di lavoro effettivo invece di una singola richiesta. Lo schema abituale è abbinare i due tipi di controllo - un controllo HTTP o ping a un minuto risponde alla domanda "il sito è raggiungibile in questo momento", mentre un controllo transazionale ogni 10 o 15 minuti risponde alla domanda più difficile se il checkout, il login o il flusso di registrazione dietro di esso funzioni ancora. Questa combinazione individua un'interruzione grave entro un minuto e un flusso non funzionante entro un ciclo di controllo, senza eseguire una sessione del browser contro la tua applicazione ogni sessanta secondi.
No, e non dovresti farlo. Un controllo transazionale invia moduli reali al tuo sito reale, quindi la configurazione corretta prevede un account di test dedicato, un prodotto o uno SKU di prova e - se il flusso arriva al pagamento - la modalità sandbox o carta di prova del tuo fornitore di pagamenti, esattamente come faresti per qualsiasi test end-to-end automatizzato. Molti team fermano lo scenario monitorato un passaggio prima dell'azione irreversibile: raggiungere la pagina di pagamento, verificare che sia stata visualizzata con il totale corretto e concludere lì. Questo dimostra comunque che ogni passaggio fino al punto vendita funziona, senza creare un ordine ogni dieci minuti. La stessa regola si applica ai flussi di registrazione e generazione lead - punta lo scenario verso un modulo di test, oppure filtra sul tuo lato gli invii del monitor, così il traffico di monitoraggio non inquina mai i tuoi dati reali.
Avvia una prova gratuita e monitora i tuoi flussi utente critici - login, ricerca, checkout - 24 ore su 24.
Fa parte del software di monitoraggio siti web di HostTracker.