Black Friday tra 20 giorni: i Suoi clienti potranno pagare? -25 % il 1° anno e configurazione offerta, fino al 30 novembreVedi l’offerta →

Ottobre 2026

Checkout in timeout ogni notte: Ping verde, Flow rosso, Chain in ritardo

PercorsiAgenzie

Di Il team di PathlyMonitoraggio dei percorsi web · 3 min di lettura ·

Negozio e-commerce (agenzia): checkout in timeout verso le 2, uptime HTTP ancora verde. Caso composito ricostruito: segnali reali, nessun cliente nominato.

Il problema di business prima dello stack

Tra le 2:00 e le 2:15 circa, gli acquirenti si bloccavano al checkout: timeout, carrello abbandonato, ticket all’assistenza il giorno dopo. Per l’agenzia, il sito «era su». Per il commerciante, la cassa era chiusa proprio quando una parte del traffico convertiva ancora.

Perché il monitoraggio classico restava verde

I check HTTP sulla home e sull’health dell’API rispondevano 200. CPU, RAM e disco non mostravano allarmi duraturi. Il percorso di pagamento non è un ping. Finché non si esegue lo scenario nel browser (carrello → spedizione → pagamento), si può rassicurare il team ops perdendo vendite.

  • Uptime HTTP ≠ percorso dell’acquirente.
  • Metriche del server ≠ latenza di business su un passaggio critico.

Caso ricostruito: come leggere questo racconto

Ricostruiamo qui un incidente tipo negozio + agenzia: orari, sintomi e lettura dei tre strumenti Pathly. Nessun marchio cliente è citato. L’interesse non è lo storytelling. È la separazione netta tra «il sito risponde» e «un acquirente può pagare».

Cosa mostrava Pathly: Ping, Flow, Chain

Ping restava verde: la vetrina e gli endpoint di health rispondevano entro le soglie. Flow diventava rosso ogni notte sul passaggio di checkout, con lo screenshot del timeout nel browser. La prova non era più un log confuso, era il percorso fallito all’ora precisa. Chain mostrava la latenza che cresceva sulle chiamate API dietro il pagamento, senza un guasto netto lato «uptime».

  • Ping: superficie HTTP OK.
  • Flow: percorso dell’acquirente KO + screenshot.
  • Chain: API dietro il checkout rallentata.

Causa: backup completo del database che blocca e rallenta

La finestra coincideva con un backup completo del database. Lock e I/O saturi rallentavano le scritture del checkout senza far cadere l’health check. Ops vedeva verde. Il business vedeva timeout. Entrambi avevano ragione sul proprio indicatore, non sullo stesso oggetto.

Correzione: spostare il backup, tenere Flow di guardia

Il team ha spostato il backup fuori dalla finestra di conversione notturna, poi ha verificato che Flow tornasse verde alla stessa ora. Tenere Flow di guardia evita di ricadere nello stesso buco: un Ping verde non basta più a chiudere l’incidente di business.

Tenere il checkout sotto gate CI

Lo stesso scenario può bloccare una pipeline dopo il deploy. L’Action pathlyhq/pathly-action@v1 avvia uno scenario e fa fallire il job se il risultato non è ok, prima che il traffico notturno riproponga lo stesso incidente.

- name: Pathly assert checkout Flow
  uses: pathlyhq/pathly-action@v1
  with:
    api-token: ${{ secrets.PATHLY_API_TOKEN }}
    operation: assert-scenario
    scenario-id: ${{ vars.PATHLY_CHECKOUT_FLOW_ID }}

Provare il percorso, non solo l’uptime

Se gestisce un negozio per un cliente, avvii un Flow sul checkout e una scansione rapida della superficie HTTP. Vedrà in pochi minuti se Ping, Flow e Chain raccontano la stessa storia.